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@xxxxxxxxxxx and that the system you're on is really host/client.example.com@xxxxxxxxxxx with a valid credential to use nfs/client.example.com@xxxxxxxxxxx at nfs/server.example.com@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
