NFS shared directory permission (rhel6)

[Ian Malone]

2011/8/1 夜神　岩男 <supergiantpotato at yahoo.co.jp>:
> 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 posting that, very handy and I know how long these things
take to write.

-- 
imalone