Dear all
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
created a directory /office
--/etc/exports---- /office *.officebox.local(rw,sync)
---ls -ld /office
drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
problem :- all the clients in officebox.local can mount the nfs shared directory on localsystem but it always mounted as read-only ...even though /etc/exports configured with read and write
I'm able to solve this problem by changing permission and set it to 777 ..... but this is not desirable
is it compulsory to set permission to 777 ... what is the batter solution ?????
Jatin K wrote:
Dear all
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
created a directory /office
--/etc/exports---- /office *.officebox.local(rw,sync)
---ls -ld /office
drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
problem :- all the clients in officebox.local can mount the nfs shared directory on localsystem but it always mounted as read-only ...even though /etc/exports configured with read and write
I'm able to solve this problem by changing permission and set it to 777 ..... but this is not desirable
is it compulsory to set permission to 777 ... what is the batter solution ?????
Probably better is set permission to (2)770 (or (2)771) and change directory group to group of accessing users. You can consider to use ACL too.
Franta Hanzlik
Around 09:23am on Monday, August 01, 2011 (UK time), Jatin K scrawled:
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
You might need to change the firewall configuration on the NFS server. There is more information here: http://www.stevesearle.co.uk/tech/faq.html#nfs0010
Steve
On 08/01/2011 05:23 PM, Jatin K wrote:
Dear all
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
created a directory /office
--/etc/exports---- /office *.officebox.local(rw,sync)
---ls -ld /office
drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
problem :- all the clients in officebox.local can mount the nfs shared directory on localsystem but it always mounted as read-only ...even though /etc/exports configured with read and write
I'm able to solve this problem by changing permission and set it to 777 ..... but this is not desirable
is it compulsory to set permission to 777 ... what is the batter solution ?????
NFSv4 has become both more awesome and more complex. Before getting into specific issues that can cause this...
What is the output of "ls -Zl" from within the share (/office, right?) from a user account? (not root) It is not enough to just see that /office is owned by root (particularly if you are checking from the root account).
Also, is /office being used as an alternative /home location or is it being used as just a common share for data?
In addition to the ownership, the SELinux context can be important (please don't tell me you went the "just turn it off" route!). What is the output of "ls -Zl" on the server side of the share, both the main share directory and inside the directory.
What is the output of "getsebool -a" on the server side?
And... are you running LDAP or NIS/NIS+, Kerberos or anything else interesting for authentication/authorization on your network? These are a huge help but also a huge subject to cram into a week of marathon self-study if you're not familiar with them already... that is if you really want to understand them and not just follow a howto without comprehending half of what you're doing.
-Iwao
On Monday 01 August 2011 02:00 PM, Frantisek Hanzlik wrote:
Jatin K wrote:
Dear all
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
created a directory /office
--/etc/exports---- /office *.officebox.local(rw,sync)
---ls -ld /office
drwxr-xr-x. 3 root root 4096 Aug 1 13:44 /office
problem :- all the clients in officebox.local can mount the nfs shared directory on localsystem but it always mounted as read-only ...even though /etc/exports configured with read and write
I'm able to solve this problem by changing permission and set it to 777 ..... but this is not desirable
is it compulsory to set permission to 777 ... what is the batter solution ?????
Probably better is set permission to (2)770 (or (2)771) and change directory group to group of accessing users. You can consider to use ACL too.
Franta Hanzlik
if I change the ownership of the directory to nfsnobody ...... is it harmful
chwon nfsnobody:nfsnobody /office
it gives me the rwx permission of the client side
changing ownership to nfsnobody is ok as per the security concern ???
On Monday 01 August 2011 02:18 PM, Steve Searle wrote:
Around 09:23am on Monday, August 01, 2011 (UK time), Jatin K scrawled:
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
You might need to change the firewall configuration on the NFS server. There is more information here: http://www.stevesearle.co.uk/tech/faq.html#nfs0010
Steve
firewall allows NFS connection to server ........ issue is no rw access is available on the sharing directory even if the /etc/exports contains rw in it
Around 01:47pm on Monday, August 01, 2011 (UK time), Jatin K scrawled:
On Monday 01 August 2011 02:18 PM, Steve Searle wrote:
Around 09:23am on Monday, August 01, 2011 (UK time), Jatin K scrawled:
what should be the permission of NFS shared directory on RHEL6 ???
I've shared a directory on rhel 6 ...following are the configuration done
You might need to change the firewall configuration on the NFS server. There is more information here: http://www.stevesearle.co.uk/tech/faq.html#nfs0010
Steve
firewall allows NFS connection to server ........ issue is no rw access is available on the sharing directory even if the /etc/exports contains rw in it
I know. If you read my website it says that the firewall can cause a file to be read-only. I've had the issue myself. If you feel it's safe, quickly drop the firewall on the NFS server and see if that cures it.
Steve
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.
References:
Recent Thread: http://www.spinics.net/lists/linux-nfs/msg22759.html Old Thread pointed by the recent discussion: http://marc.info/?t=123739823200003&r=1&w=2
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
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 )
thanks for your valuable inputs and suggestions
Warm Regards
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@EXAMPLE.COM and that the system you're on is really host/client.example.com@EXAMPLE.COM with a valid credential to use nfs/client.example.com@EXAMPLE.COM at nfs/server.example.com@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
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@EXAMPLE.COM and that the system you're on is really host/client.example.com@EXAMPLE.COM with a valid credential to use nfs/client.example.com@EXAMPLE.COM at nfs/server.example.com@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
On Monday 01 August 2011 08:11 PM, 夜神 岩男 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@EXAMPLE.COM and that the system you're on is really host/client.example.com@EXAMPLE.COM with a valid credential to use nfs/client.example.com@EXAMPLE.COM at nfs/server.example.com@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
Thank you very very much for you efforts ..... its really a informative lines
Thanks again
On 08/02/2011 01:09 AM, Mike Wright wrote:
On 08/01/2011 07:41 AM, 夜神 岩男 wrote:
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.
Great need plants great seed, doesn't it? (Whoa! That sort of sounds like old wisdom! English is fun!)
(Unfortunately, in order to debug my setup I've resorted to "Step 1", which sometimes helps and other times not so much.)
I supposed Step 2 should always be set to "revert Step 1"!
I will put my notes together and make a series out of it -- looking around the web and in books this sort of thing really *doesn't* seem to be documented well and stumps a huge number of people who just give up and assume that good Linux setups are just too hard to bother with. This is because:
1. The cn=config style of OpenLDAP is undocumented and very confusing for newcomers
(Initial setup for the first time reliably produces feelings between simmering-rage-type frustration or the breaking-things-in-the-office point. Some things the OpenLDAP manual should have in it under configuration just aren't there, and it makes the manual *feel* inaccurate though it doesn't actually state anything that is wrong... which is worse, because it makes it believable *and* wrong instead of clearly, igorably wrong...)
2. Kerberos seems scary at first and though quite simple to understand after playing with it a bit, the documentation goes to such length to "make a hard subject easy" that the reader defaults to the assumption that it *is* hard -- which is not as true as it may feel.
(...and the part when you decide that you're actually going to switch authentication over is a little nerve-wracking so some admins just don't go through with it -- its like the first time you decided to actually turn SSH password authentication off on a really remote system, but multiplied by however many systems your servicing raised to the power of however much your contract is worth)
3. Our users have been trained to expect such shit tech from whatever contact they had with bad Windows administration in the past that we can get away with being lazy and not doing things correctly. ("Put it on the shared drive" comes to mind...)
(The Post-Windows Crutch -- where we continue to not let users experience seamless networking to the natural degree, where they don't even realize what terminal they are using because everything is the same from every station -- because its all the same system if things are working the way they were originally designed)
4. The interactions between the little team of necessary daemons is so scantily explained that most admins that get to the point of an actually complete configuration fail because unthought-of-yet-critical daemons aren't started. Two of the biggest culprits on Fedora are nscd and nslcd.
(The last sentence above is today's hint -- discovered after seeing what would happen if a working SL6 setup was pushed directly to a Fedora 14 system. nscd, nslcd weren't even installed with the dependencies for the setup, and sssd was present in the system but no scripts that require it (like authconfig-tui) called "chkconfig sssd on" for some reason... Of course none of these problems produced remotely accurate error messages any place that the uninitiated would think to look (or at all)...)
5. CA and signed-certificate creation is a fun subject full of myth and wildly inaccurate or out of date tutorials (or tutorials specific to, say, FreeBSD or Darwin/OSX, but don't clearly state that). Its confusing and ill-treated enough that some people give up and just shell out money for them, even if the certification is strictly internal.
6. NFSv4 and OpenAFS are great tools, but suffer from a lack of accurate documentation in a similar way to the CA subject. Why is sort of beyond me, because they are both widely deployed, but only by people who either paid to learn the magical secrets (and after climbing the learning curve myself, I have to say this is probably a worthwhile option) or were burned about the time they understood everything and were too worn out thinking on the subject to post their notes (I think most of us can appreciate that feeling after certain experiences).
Blah blah blah. Yes, an in-depth tutorial is sorely needed (really this calls for another O'Reilly book in my opinion, but you'll have to settle for whatever I've got spare time for + outdated web resources and... man/info pages -- haha!).
-Iwao
PS: I've got to finish a magazine article that Akemi Yagi and I are writing for a Japanese journal out here (she's the main author, not me, but its hard doing English/Japanese, so this is more time consuming than usual for me) -- so this will have to wait just a little. I'll post to the list when I'm done, though, or at least send you folks a private notice. Not sure that it really applies to everyone here so much as to warrant plugging my tutorial on-list...
2011/8/1 夜神 岩男 supergiantpotato@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@EXAMPLE.COM and that the system you're on is really host/client.example.com@EXAMPLE.COM with a valid credential to use nfs/client.example.com@EXAMPLE.COM at nfs/server.example.com@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.
On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle steve@stevesearle.co.uk wrote:
I know. If you read my website it says that the firewall can cause a file to be read-only.
Which firewall settings cause NFS exports to be ro?
2011/8/1 夜神 岩男 supergiantpotato@yahoo.co.jp:
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@EXAMPLE.COM and that the system you're on is really host/client.example.com@EXAMPLE.COM with a valid credential to use nfs/client.example.com@EXAMPLE.COM at nfs/server.example.com@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.
NFSv4 works without Kerberos or LDAP/NIS/NIS+.
The username and idmapd domain have to match (perhaps the UID too but I've never tried different UIDs as you suggest above and the description of idmapd does say that the ID is sent as username@domain).
On 08/03/2011 02:05 AM, Tom H wrote:
NFSv4 works without Kerberos or LDAP/NIS/NIS+.
Of course it does, but can the permissions be exported per user by UID/GID mask or are the exports still blanket ro/rw (which is the real point of this thread)? Further, can you escape from the nfs_mount_t context and give native SELinux contexts to the export on the client side with this setup?
(That would be really cooking from one perspective, but also pretty insecure without authentication -- which is why I had always been under the impression that this was specifically forbidden.)
The username and idmapd domain have to match (perhaps the UID too but I've never tried different UIDs as you suggest above and the description of idmapd does say that the ID is sent as username@domain).
That would be neat.
Can you direct me to a sample idmapd configuration that achieves this: rpc.idmapd + hostname-declared domains that are common (does DNS need to be enabled for this?) + /etc/passwd and /etc/group files + NFSv4 UIDs and GIDs accurately mapped for permissions across exports (not just ro or blanket rw).
It could fill in some holes and perhaps I've just never been able to find the right way to make idmapd domains stick with SELinux enabled without using some form of authentication. Is sssd or nslcd or nscd required somewhere in there, or do these just satisfy Kerberos requirements?
If I can get a configuration like this working it would help the OP in the short run, and provide more insight for the tutorial I want to write.
-Iwao
Around 05:51pm on Tuesday, August 02, 2011 (UK time), Tom H scrawled:
On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle steve@stevesearle.co.uk wrote:
I know. If you read my website it says that the firewall can cause a file to be read-only.
Which firewall settings cause NFS exports to be ro?
I already pointed to the webpage. Its here: http://www.stevesearle.com/tech/faq.html#nfs0010
I'm not going to rewrite it in an email
Steve
On Tue, Aug 2, 2011 at 3:57 PM, Steve Searle steve@stevesearle.co.uk wrote:
Around 05:51pm on Tuesday, August 02, 2011 (UK time), Tom H scrawled:
On Mon, Aug 1, 2011 at 8:57 AM, Steve Searle steve@stevesearle.co.uk wrote:
I know. If you read my website it says that the firewall can cause a file to be read-only.
Which firewall settings cause NFS exports to be ro?
I already pointed to the webpage. Its here: http://www.stevesearle.com/tech/faq.html#nfs0010
I'm not going to rewrite it in an email
Where on your page does it say: "to export an nfs share r/o, use the following iptables rules?"
On 08/03/2011 04:57 AM, Steve Searle wrote:
Around 05:51pm on Tuesday, August 02, 2011 (UK time), Tom H scrawled:
On Mon, Aug 1, 2011 at 8:57 AM, Steve Searlesteve@stevesearle.co.uk wrote:
I know. If you read my website it says that the firewall can cause a file to be read-only.
Which firewall settings cause NFS exports to be ro?
I already pointed to the webpage. Its here: http://www.stevesearle.com/tech/faq.html#nfs0010
I'm not going to rewrite it in an email
This is not what I have experienced with NFSv4. NFSv3 had specific port requirements for random rpc daemons, but with NFSv4 you only need TCP 2049 open (or whatever you set it to) -- that was one of the more tangible improvements over the previous versions.
And this is what I meant about documentation on the subject being generally out of date or not accurate as per the current Linux standard (as in, not Solaris circa 2001 documentation...).
The following iptables were exported from a server running SSH (tcp 22) OpenLDAP (tcp 389), NFSv4 (tcp 2049) and Kerberos KDC/Kadmin (88 and 749). This server provides rw exports with authenticated rw file permissions and correct SELinux contexts for several shares:
# Generated by iptables-save v1.4.7 on Wed Aug 3 13:41:04 2011 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [4538677:6498063300] -A INPUT -p tcp -m tcp --dport 88 -j ACCEPT -A INPUT -p udp -m udp --dport 88 -j ACCEPT -A INPUT -p udp -m udp --dport 749 -j ACCEPT -A INPUT -p tcp -m tcp --dport 749 -j ACCEPT -A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 389 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Wed Aug 3 13:41:04 2011
-Iwao
-
Franta Hanzlík -
Ian Malone -
Jatin K -
Mike Wright -
Robert Marcano -
Steve Searle -
Tom H -
夜神 岩男