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 at EXAMPLE.COM and that the 
system you're on is really host/client.example.com at EXAMPLE.COM with a 
valid credential to use nfs/client.example.com at EXAMPLE.COM at 
nfs/server.example.com at 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