NFSD ignores group permissions

H

hermes

Ok, scenario is as follows:

I want to export several ZFS filesystems via NFS. The permissions on these folders are 750, with a few files 700. I’d like to set up an unprivileged user who is able to access these folders with group privileges, so that I can map all UIDs to this user without either giving away any ‘only readable by owner’ files or making the folder world-readable.
This works alright locally: I can access exactly the files that I’m supposed to (as that user, in a shell), but whenever I mount the NFS export from another machine, the whole filesystem is unreadable, i.e. group permissions are completely ignored by nfsd. It works completely fine when either mapping UIDs to the owner or chmodding stuff 755, but that’s not the way I want to do it :/

Is this reproducable for you?
 
Keep in mind that the client doesn't see the 'groups' or 'users'. It only sees UIDs and GIDs. A user on a client can have a different UID from that same user account on the server. Similar for groups.

The only way to 'solve' this is to make sure all UIDs and GIDs are the same on all machines. And to make sure your users are members of the same groups on all servers. One way to solve this is by using a centralized account database with LDAP i.e.
 
Even as root on the client the problem persists. It’s definitely the server not allowing me to access files that are readable for the group, but not for everyone.
 
hermes said:
Even as root on the client the problem persists. It’s definitely the server not allowing me to access files that are readable for the group, but not for everyone.
Click to expand...

Unless you have specifically allowed root to an nfs share(ie -maproot) then a root user from a client will be given the lowest possible access rights(either nobody/nogroup) or the uid/gid numbers of -2/-2(ie non existing users). So that's by design of the NFS protocol.

The easiest way to see if your UID/GID match up is to issue this on both servers$ id This will show you all the uid/gid information, and you can see if they match up(which they probably won't). Also remeber to check for GID's present on the client what they represent on the server, as that can be a huge security risk if a client is part of a group that has special rights on the server.
 
From exports(5):
-maproot=user The credential of the specified user is used for remote
access by root. The credential includes all the groups to which the user
is a member on the local machine (see id(1)). The user may be specified
by name or number.

-maproot=user:group1:group2:... The colon separated list is used to spec‐
ify the precise credential to be used for remote access by root. The
elements of the list may be either names or numbers. Note that user:
should be used to distinguish a credential containing no groups from a
complete credential for that user.

-mapall=user or -mapall=user:group1:group2:... specifies a mapping for
all client UIDs (including root) using the same semantics as -maproot.

The option -r is a synonym for -maproot in an effort to be backward com‐
patible with older export file formats.

In the absence of -maproot and -mapall options, remote accesses by root
will result in using a credential of -2:-2. All other users will be
mapped to their remote credential. If a -maproot option is given, remote
access by root will be mapped to that credential instead of -2:-2. If a
-mapall option is given, all users (including root) will be mapped to
that credential in place of their own.
Click to expand...

So that’s not true?

EDIT: It also works perfectly the other way around, i.e. exporting a filesystem on the Debian client, mapping everybody to nobody:1000 and mounting it as root on FreeBSD. I really think this is the FreeBSD NFS Server which is granting access rights based on just the UID that the remote user is mapped to and not the GID. I’ll have a look if I can find anything in the source code.
 
on nfsserver

Code: 
gnome:~# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
gnome:~# id tl
uid=1000(tl) gid=1000(tl) groups=1000(tl),0(wheel)

gnome:~# mkdir -p /data/groupreadable/test
gnome:~# chmod 750 /data/groupreadable/test
gnome:~# mkdir -p /data/notgroupreadable/test
gnome:~# chgrp daemon /data/notgroupreadable
gnome:~# chmod 700 /data/notgroupreadable

gnome:~# ls -ld /data/*group*
drwxr-x---  3 root  wheel   512 May 30 18:18 /data/groupreadable/
drwx------  3 root  daemon  512 May 30 18:19 /data/notgroupreadable/

gnome:~# grep data /etc/exports
/data   -maproot=root

on nfsclient

Code: 
gong:~% id
uid=1000(tl) gid=1000(tl) groups=1000(tl),0(wheel)

gong:~% mount |grep data
gnome:/data on /data (nfs, noatime)

gong:~% ls -ld /data/*group*
drwxr-x---  3 root  wheel   512 May 30 18:18 /data/groupreadable//
drwx------  3 root  daemon  512 May 30 18:19 /data/notgroupreadable/

gong:~% ls /data/*group*
/data/groupreadable/:
test/

/data/notgroupreadable/:
ls: /data/notgroupreadable/: Permission denied

gong:~% touch /data/groupreadable/another
touch: /data/groupreadable/another: Permission denied

I.e, group permissions work as advertised.
 
Of course it’s readable if you map root from the client to root on the server. What you were testing is a 1:1 mapping of UIDs/GIDs. The problem is however the server not allowing a client mapped to a GID which should be able to read a file (and is indeed able to do so locally) to read that file over NFS. Try:

On the server:
Code: 
# chown tl:tl /data/groupreadable/test
# chown tl:tl /data/notgroupreadable
In /etc/exports:
Code: 
/data -mapall=nobody:tl

Then mount it on the client (as root) and see if you can access /data/groupreadable/test (also as root if you wish).
 
Okay
Code: 
gnome:~# chown -R tl:tl /data/*group*
gnome:~# grep data /etc/exports
/data   -mapall=nobody:tl
gnome:~# killall -1 mountd

as user tl on gong everything still behave as expected
Code: 
gong:~% df|grep data
gnome:/data           44G     22G     18G    55%    /data

gong:~% id
uid=1000(tl) gid=1000(tl) groups=1000(tl),0(wheel)

gong:~% ls  /data/*group*
/data/groupreadable:
test/

/data/notgroupreadable:
ls: /data/notgroupreadable: Permission denied

verify that group credentials are in effect - groupreadable is read-only

Code: 
gong:~% touch /data/groupreadable/x
touch: /data/groupreadable/x: Permission denied

After chmod 770 on gnome:/data/groupreadable the result is

Code: 
gong:~% touch /data/groupreadable/x
gong:~% ls -l /data/groupreadable/x
-rw-r--r--  1 nobody  tl  0 May 31 10:52 /data/groupreadable/x
 
Ok, this is strange: Group permissions work fine if I omit the -network and -mask options in /etc/exports. This should have no effect at all on permissions, right? :/
 
I can confirm this behaviour with 8.0-RELEASE-p2.

I have a set of files and directories on ZFS owned by u1:g1, with permissions of 750/640. I am trying to access this from a Mac using NFS. There is no synchronisation of uids between the systems, so I'm trying to use -mapall.

With:

Code: 
sharenfs="-ro -mapall=nobody:g1 -network=192.168.2.0/24"

I can mount the filesystem, but get permissions errors when trying to access anything.

With:

Code: 
sharenfs="-ro -mapall=nobody:g1"

I can mount the filesystem and access it without problems.


This is a regression since 7.2, where I had a very similar configuration (using -mapall=u2, with u2 being a member of g1) that worked. I've tried this (instead of -mapall=nobody:g1) on 8.0-RELEASE-p2 with identical results.
 
You must log in or register to reply here.
Back
Top