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(a)EXAMPLE.COM and that the
system you're on is really host/client.example.com(a)EXAMPLE.COM with a
valid credential to use nfs/client.example.com(a)EXAMPLE.COM at
nfs/server.example.com(a)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