FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 08-01-2011, 12:33 PM
夜神 岩男
 
Default NFS shared directory permission (rhel6)

On 08/01/2011 05:23 PM, Jatin K wrote:
> Dear all
>
> what should be the permission of NFS shared directory on RHEL6 ???
>
> I've shared a directory on rhel 6 ...following are the configuration done
>
> created a directory /office
>
> --/etc/exports----
> /office *.officebox.local(rw,sync)
>
>
>
> ---ls -ld /office
>
> drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
>
>
> problem :- all the clients in officebox.local can mount the nfs shared
> directory on localsystem but it always mounted as read-only ...even
> though /etc/exports configured with read and write
>
> I'm able to solve this problem by changing permission and set it to 777
> ..... but this is not desirable
>
> is it compulsory to set permission to 777 ... what is the batter
> solution ?????

NFSv4 has become both more awesome and more complex.
Before getting into specific issues that can cause this...

What is the output of "ls -Zl" from within the share (/office, right?)
from a user account? (not root) It is not enough to just see that
/office is owned by root (particularly if you are checking from the root
account).

Also, is /office being used as an alternative /home location or is it
being used as just a common share for data?

In addition to the ownership, the SELinux context can be important
(please don't tell me you went the "just turn it off" route!). What is
the output of "ls -Zl" on the server side of the share, both the main
share directory and inside the directory.

What is the output of "getsebool -a" on the server side?

And... are you running LDAP or NIS/NIS+, Kerberos or anything else
interesting for authentication/authorization on your network?
These are a huge help but also a huge subject to cram into a week of
marathon self-study if you're not familiar with them already... that is
if you really want to understand them and not just follow a howto
without comprehending half of what you're doing.

-Iwao
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 12:45 PM
Jatin K
 
Default NFS shared directory permission (rhel6)

On Monday 01 August 2011 02:00 PM, Frantisek Hanzlik wrote:
> Jatin K wrote:
>> Dear all
>>
>> what should be the permission of NFS shared directory on RHEL6 ???
>>
>> I've shared a directory on rhel 6 ...following are the configuration done
>>
>> created a directory /office
>>
>> --/etc/exports----
>> /office *.officebox.local(rw,sync)
>>
>>
>>
>> ---ls -ld /office
>>
>> drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
>>
>>
>> problem :- all the clients in officebox.local can mount the nfs shared
>> directory on localsystem but it always mounted as read-only ...even
>> though /etc/exports configured with read and write
>>
>> I'm able to solve this problem by changing permission and set it to 777
>> ..... but this is not desirable
>>
>> is it compulsory to set permission to 777 ... what is the batter
>> solution ?????
> Probably better is set permission to (2)770 (or (2)771) and change
> directory group to group of accessing users.
> You can consider to use ACL too.
>
> Franta Hanzlik
>

if I change the ownership of the directory to nfsnobody ...... is it
harmful


chwon nfsnobody:nfsnobody /office

it gives me the rwx permission of the client side


changing ownership to nfsnobody is ok as per the security concern ???

--
v
/(_)
^ ^ Jatin Khatri
Registerd Linux user No #501175
www.counter.li.org
No M$

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 12:45 PM
Jatin K
 
Default NFS shared directory permission (rhel6)

On Monday 01 August 2011 02:00 PM, Frantisek Hanzlik wrote:
> Jatin K wrote:
>> Dear all
>>
>> what should be the permission of NFS shared directory on RHEL6 ???
>>
>> I've shared a directory on rhel 6 ...following are the configuration done
>>
>> created a directory /office
>>
>> --/etc/exports----
>> /office *.officebox.local(rw,sync)
>>
>>
>>
>> ---ls -ld /office
>>
>> drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
>>
>>
>> problem :- all the clients in officebox.local can mount the nfs shared
>> directory on localsystem but it always mounted as read-only ...even
>> though /etc/exports configured with read and write
>>
>> I'm able to solve this problem by changing permission and set it to 777
>> ..... but this is not desirable
>>
>> is it compulsory to set permission to 777 ... what is the batter
>> solution ?????
> Probably better is set permission to (2)770 (or (2)771) and change
> directory group to group of accessing users.
> You can consider to use ACL too.
>
> Franta Hanzlik
>

if I change the ownership of the directory to nfsnobody ...... is it
harmful


chwon nfsnobody:nfsnobody /office

it gives me the rwx permission of the client side


changing ownership to nfsnobody is ok as per the security concern ???

--
v
/(_)
^ ^ Jatin Khatri
Registerd Linux user No #501175
www.counter.li.org
No M$

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 12:47 PM
Jatin K
 
Default NFS shared directory permission (rhel6)

On Monday 01 August 2011 02:18 PM, Steve Searle wrote:
> Around 09:23am on Monday, August 01, 2011 (UK time), Jatin K scrawled:
>
>> what should be the permission of NFS shared directory on RHEL6 ???
>>
>> I've shared a directory on rhel 6 ...following are the configuration done
> You might need to change the firewall configuration on the NFS server.
> There is more information here:
> http://www.stevesearle.co.uk/tech/faq.html#nfs0010
>
> Steve
>
firewall allows NFS connection to server ........ issue is no rw access
is available on the sharing directory even if the /etc/exports contains
rw in it

--
v
/(_)
^ ^ Jatin Khatri
Registerd Linux user No #501175
www.counter.li.org
No M$

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 12:57 PM
Steve Searle
 
Default NFS shared directory permission (rhel6)

Around 01:47pm on Monday, August 01, 2011 (UK time), Jatin K scrawled:

> On Monday 01 August 2011 02:18 PM, Steve Searle wrote:
> > Around 09:23am on Monday, August 01, 2011 (UK time), Jatin K scrawled:
> >
> >> what should be the permission of NFS shared directory on RHEL6 ???
> >>
> >> I've shared a directory on rhel 6 ...following are the configuration done
> > You might need to change the firewall configuration on the NFS server.
> > There is more information here:
> > http://www.stevesearle.co.uk/tech/faq.html#nfs0010
> >
> > Steve
> >
> firewall allows NFS connection to server ........ issue is no rw access
> is available on the sharing directory even if the /etc/exports contains
> rw in it

I know. If you read my website it says that the firewall can cause a
file to be read-only. I've had the issue myself. If you feel it's safe,
quickly drop the firewall on the NFS server and see if that cures it.

Steve

--

Website: www.stevesearle.com
Twitter: @ReddishShift
Facebook: www.facebook.com/steve.searle

13:55:55 up 5:15, 3 users, load average: 0.00, 0.00, 0.00
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 12:59 PM
Robert Marcano
 
Default NFS shared directory permission (rhel6)

On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
...

> NFSv4 has become both more awesome and more complex.
> Before getting into specific issues that can cause this...
>

If you intend to use POSIX ACLs with NFSv4 forget about it, because user
umask is always applied at the client side over the default POSIX ACLs
making difficult to have for example rw directory/files for some group
of users.

References:

Recent Thread:
http://www.spinics.net/lists/linux-nfs/msg22759.html
Old Thread pointed by the recent discussion:
http://marc.info/?t=123739823200003&r=1&w=2

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 01:11 PM
夜神 岩男
 
Default NFS shared directory permission (rhel6)

On 08/01/2011 09:59 PM, Robert Marcano wrote:
> On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
> ...
>
>> NFSv4 has become both more awesome and more complex.
>> Before getting into specific issues that can cause this...
>>
>
> If you intend to use POSIX ACLs with NFSv4 forget about it, because user
> umask is always applied at the client side over the default POSIX ACLs
> making difficult to have for example rw directory/files for some group
> of users.

That is part of what I am trying to discover by asking him for the
output I wrote and more about the authentication/authorization situation
on the network. There are a large number of reasons permissions can get
kajiggered over the network with NFSv4 or AFS, and in an office
environment doubly so because of the prevalence of LDAP, NIS and
Kerberos deployments, along with SELinux fun tossed in.

-Iwao
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 01:25 PM
Jatin K
 
Default NFS shared directory permission (rhel6)

On Monday 01 August 2011 06:41 PM, 夜神 岩男 wrote:
> On 08/01/2011 09:59 PM, Robert Marcano wrote:
>> On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
>> ...
>>
>>> NFSv4 has become both more awesome and more complex.
>>> Before getting into specific issues that can cause this...
>>>
>> If you intend to use POSIX ACLs with NFSv4 forget about it, because user
>> umask is always applied at the client side over the default POSIX ACLs
>> making difficult to have for example rw directory/files for some group
>> of users.
> That is part of what I am trying to discover by asking him for the
> output I wrote and more about the authentication/authorization situation
> on the network. There are a large number of reasons permissions can get
> kajiggered over the network with NFSv4 or AFS, and in an office
> environment doubly so because of the prevalence of LDAP, NIS and
> Kerberos deployments, along with SELinux fun tossed in.
>
> -Iwao

no there is no LDAP or NIS like stuff

I'm thinking to use ACL on that directory based on the user groups ( in
my scenario it will be office user groups )



thanks for your valuable inputs and suggestions

Warm Regards


--
°v°
/(_)
^ ^ Jatin Khatri
Registerd Linux user No #501175
www.counter.li.org
No M$

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 02:41 PM
夜神 岩男
 
Default NFS shared directory permission (rhel6)

On 08/01/2011 10:25 PM, Jatin K wrote:
> On Monday 01 August 2011 06:41 PM, 夜神 岩男 wrote:
>> On 08/01/2011 09:59 PM, Robert Marcano wrote:
>>> On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
>>> ...
>>>
>>>> NFSv4 has become both more awesome and more complex.
>>>> Before getting into specific issues that can cause this...
>>>>
>>> If you intend to use POSIX ACLs with NFSv4 forget about it, because user
>>> umask is always applied at the client side over the default POSIX ACLs
>>> making difficult to have for example rw directory/files for some group
>>> of users.
>> That is part of what I am trying to discover by asking him for the
>> output I wrote and more about the authentication/authorization situation
>> on the network. There are a large number of reasons permissions can get
>> kajiggered over the network with NFSv4 or AFS, and in an office
>> environment doubly so because of the prevalence of LDAP, NIS and
>> Kerberos deployments, along with SELinux fun tossed in.
>>
>> -Iwao
>
> no there is no LDAP or NIS like stuff
>
> I'm thinking to use ACL on that directory based on the user groups ( in
> my scenario it will be office user groups )

You can achieve the same user and group permissions on the clients as on
the server, but you have to create the users and groups on the server
side to get this and you must use some form of authentication across the
network. The server exports the user names and group names, not the
numbers, so a translation must occur within rpc.idmapd as well. Its not
as hard as it sounds -- most of it "just works" once you set up
authentication.

This can happen through the /etc/passwd and /etc/groups files, using
them as a local directory (which is easy, because this is already the
default -- in a directory-enabled environment this is easier to maintain
over the long run, though).

Create the users and groups on the server that exist on your clients.
Don't worry about the UID and GID numbers matching, they don't need to.
Make sure the user and group names are the same, though.

Then make sure that you do:
setsebool -P nfs_export_all_ro=0
setsebool -P nfs_export_all_rw=1

and that in your /etc/exports you have the correct permissions declared
for the export. It is also easier to manage a lot of shares if you are
using the fsid=0 style export directory trees, though I don't think this
is strictly necessary.

And, critically... you must pick an authentication mechanism that
rpc.idmapd likes.

The easiest one is Kerberos, and its really not that difficult to set
up. Once a Kerberos ticket exists for authentication, then the NFS
server will believe that you're really user@EXAMPLE.COM and that the
system you're on is really host/client.example.com@EXAMPLE.COM with a
valid credential to use nfs/client.example.com@EXAMPLE.COM at
nfs/server.example.com@EXAMPLE.COM and pass UID/GID information to the
client.

You don't really *need* directory services like LDAP or NIS, but without
using authentication I don't think there is a way to get NFSv4 to pass
UID/GID information. The reason is that passing this data leaves it up
to the client to decide how to handle security, and that is not secure
at all.

For example, if you had "192.168.0.0/24(rw)" in your /etc/exports then
anyone who gets into your wireless could just declare UIDs and GIDs and
do whatever they wanted with your data (from a security perspective it
is the same thing as exporting mod 777 shares). By requiring
authentication this problem goes away, and by removing anonymous
authentication as an option the temptation to screw yourself also goes
away. In other words if you're exporting mod 777 you have to explicitely
set things up that way with NFSv4, and this is a Good Thing.

There are a lot of threads out there by people who don't understand how
authenticated NFSv4 works, most of them ranting about how "stupid"
idmapd, Kerberos, LDAP, or nsswitch is -- or they are just threads where
people declare, en masse, that "permissions over NFSv4 just can't
happen" in a despairing tone. But again, these people don't understand
how the system functions very well.

I have really been meaning to collect my notes about small/medium office
Kerberos/LDAP/NFSv4 setup and write a small series on how to do this
without giving up, settling for less (ie. logically unauthenticated
Samba or using just LDAP as if it were actually an authentication
service and a directory), or jumping off of a bridge.

If you run into bad spots, keep asking. If I actually write a how-to
about this I'll send you a link. Beware that most of the how-tos out
there are pretty out of date, don't take SELinux into account or make
other assumptions that don't line up with RPM-based systems (or do
boneheaded things like say "Step 1, turn off SELinux").

-Iwao
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 08-01-2011, 04:09 PM
Mike Wright
 
Default NFS shared directory permission (rhel6)

On 08/01/2011 07:41 AM, 夜神 岩男 wrote:
> On 08/01/2011 10:25 PM, Jatin K wrote:
>> On Monday 01 August 2011 06:41 PM, 夜神 岩男 wrote:
>>> On 08/01/2011 09:59 PM, Robert Marcano wrote:
>>>> On 08/01/2011 08:03 AM, 夜神 岩男 wrote:
>>>> ...
>>>>
>>>>> NFSv4 has become both more awesome and more complex.
>>>>> Before getting into specific issues that can cause this...
>>>>>
>>>> If you intend to use POSIX ACLs with NFSv4 forget about it, because user
>>>> umask is always applied at the client side over the default POSIX ACLs
>>>> making difficult to have for example rw directory/files for some group
>>>> of users.
>>> That is part of what I am trying to discover by asking him for the
>>> output I wrote and more about the authentication/authorization situation
>>> on the network. There are a large number of reasons permissions can get
>>> kajiggered over the network with NFSv4 or AFS, and in an office
>>> environment doubly so because of the prevalence of LDAP, NIS and
>>> Kerberos deployments, along with SELinux fun tossed in.
>>>
>>> -Iwao
>>
>> no there is no LDAP or NIS like stuff
>>
>> I'm thinking to use ACL on that directory based on the user groups ( in
>> my scenario it will be office user groups )
>
> You can achieve the same user and group permissions on the clients as on
> the server, but you have to create the users and groups on the server
> side to get this and you must use some form of authentication across the
> network. The server exports the user names and group names, not the
> numbers, so a translation must occur within rpc.idmapd as well. Its not
> as hard as it sounds -- most of it "just works" once you set up
> authentication.
>
> This can happen through the /etc/passwd and /etc/groups files, using
> them as a local directory (which is easy, because this is already the
> default -- in a directory-enabled environment this is easier to maintain
> over the long run, though).
>
> Create the users and groups on the server that exist on your clients.
> Don't worry about the UID and GID numbers matching, they don't need to.
> Make sure the user and group names are the same, though.
>
> Then make sure that you do:
> setsebool -P nfs_export_all_ro=0
> setsebool -P nfs_export_all_rw=1
>
> and that in your /etc/exports you have the correct permissions declared
> for the export. It is also easier to manage a lot of shares if you are
> using the fsid=0 style export directory trees, though I don't think this
> is strictly necessary.
>
> And, critically... you must pick an authentication mechanism that
> rpc.idmapd likes.
>
> The easiest one is Kerberos, and its really not that difficult to set
> up. Once a Kerberos ticket exists for authentication, then the NFS
> server will believe that you're really user@EXAMPLE.COM and that the
> system you're on is really host/client.example.com@EXAMPLE.COM with a
> valid credential to use nfs/client.example.com@EXAMPLE.COM at
> nfs/server.example.com@EXAMPLE.COM and pass UID/GID information to the
> client.
>
> You don't really *need* directory services like LDAP or NIS, but without
> using authentication I don't think there is a way to get NFSv4 to pass
> UID/GID information. The reason is that passing this data leaves it up
> to the client to decide how to handle security, and that is not secure
> at all.
>
> For example, if you had "192.168.0.0/24(rw)" in your /etc/exports then
> anyone who gets into your wireless could just declare UIDs and GIDs and
> do whatever they wanted with your data (from a security perspective it
> is the same thing as exporting mod 777 shares). By requiring
> authentication this problem goes away, and by removing anonymous
> authentication as an option the temptation to screw yourself also goes
> away. In other words if you're exporting mod 777 you have to explicitely
> set things up that way with NFSv4, and this is a Good Thing.
>
> There are a lot of threads out there by people who don't understand how
> authenticated NFSv4 works, most of them ranting about how "stupid"
> idmapd, Kerberos, LDAP, or nsswitch is -- or they are just threads where
> people declare, en masse, that "permissions over NFSv4 just can't
> happen" in a despairing tone. But again, these people don't understand
> how the system functions very well.
>
> I have really been meaning to collect my notes about small/medium office
> Kerberos/LDAP/NFSv4 setup and write a small series on how to do this
> without giving up, settling for less (ie. logically unauthenticated
> Samba or using just LDAP as if it were actually an authentication
> service and a directory), or jumping off of a bridge.
>
> If you run into bad spots, keep asking. If I actually write a how-to
> about this I'll send you a link. Beware that most of the how-tos out
> there are pretty out of date, don't take SELinux into account or make
> other assumptions that don't line up with RPM-based systems (or do
> boneheaded things like say "Step 1, turn off SELinux").
>

Thanks for your efforts, Iwao.

Sign me up, too. A link would be *great*.

One of my biggest plaints is that much of the documentation out there
lacks date and/or version info.

Now that I've got Xen up and going and have more than a few virtual
machines running it's becoming difficult/awkward to keep track of
users/passwords, dealing with uid/gid being different for the same users
on different machines, and especially nfs. Some vms will happily mount
from one nfs server while others to the same server give me errors, all
with the same version of the same o/s.

(Unfortunately, in order to debug my setup I've resorted to "Step 1",
which sometimes helps and other times not so much.)

Mike Wright
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 

Thread Tools




All times are GMT. The time now is 08:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org