NFS shared directory permission (rhel6)

[Mike Wright]

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 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").
>

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