2011/8/1 夜神 岩男 <supergiantpotato@xxxxxxxxxxx>: > 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"). > Thanks for posting that, very handy and I know how long these things take to write. -- imalone -- 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
