[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFSv4 without Kerberos and permissions

On 10/16/2017 3:35 PM, Christian Seiler wrote:
On 10/16/2017 07:57 PM, John Ratliff wrote:
On 10/15/2017 3:38 AM, Christian Seiler wrote:
Furthermore, the MANAGED_GIDS setting is only for NFSv2/3 and only
for supplementary groups, not the primary group. It is not a security
setting, it really is just for bypassing the 16 group limit of older
NFS protocols, and is useless with NFSv4.

I'm not sure this is entirely the case. Turning off managed GIDs and
using an NFSv4 mount (i.e. on client: mount -t nfs4 blahblahblah),
this let me use secondary groups on the server. Before, I could not.

Sorry, you're right. rpc.mountd is typically only NFSv2/3, but with
NFSv4 it does provide some corner case functionality (I rechecked
the code just now) and MANAGED_GIDS is one of those.

Okay, I am unable to make this work. Perhaps I am still confused as to how id mapping works.

Here is my test setup.

1) Debian 9 NFS4 Server

/etc/hosts.deny is empty

iptables is wide open.

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Server is on

/etc/exports is


I have set nfs_disable_idmapping to 0

$ cat /sys/module/nfsd/parameters/nfs4_disable_idmapping

This is my /srv/nfs4 file structure:

$ ls -lR /srv/nfs4
total 4
drwxr-sr-x 3 root ssl-cert 4096 Oct 19 20:01 ssl

total 12
-rw-r----- 1 root ssl-cert   24 Oct 19 18:43 private.txt
-rw-r--r-- 1 root ssl-cert   22 Oct 19 18:43 public.txt
drwxr-s--- 2 root ssl-cert 4096 Oct 19 18:43 wildcard

total 8
-rw-r----- 1 root ssl-cert 24 Oct 19 18:43 private.txt
-rw-r--r-- 1 root ssl-cert 22 Oct 19 18:43 public.txt

There are five users on the server. These are their permissions:

$ id jratliff
uid=1000(jratliff) gid=1000(jratliff) groups=1000(jratliff),27(sudo),100(users),112(ssl-cert)

$ id jbail
uid=1001(jbail) gid=1001(jbail) groups=1001(jbail),27(sudo),100(users)

$ id john
uid=1003(john) gid=1003(john) groups=1003(john),112(ssl-cert)

$ id matt
uid=2049(matt) gid=2049(matt) groups=2049(matt),112(ssl-cert)

$ id austin
uid=2050(austin) gid=2050(austin) groups=2050(austin)

Based on this configuration, I would expect the following:

Users jratliff@domain, john@domain, and matt@domain should be able to read the private.txt file and enter the wildcard directory.

Users jbail@domain and austin@domain should not be able to do those things.

2) Ubuntu 14.04 LTS Client

Very similar settings. Open tcp wrappers, open firewalls, same subnet (

I removed nfs4_disable_idmapping in both the nfsd and nfs modules.

$ cat /sys/module/nfsd/parameters/nfs4_disable_idmapping

$ cat /sys/module/nfs/parameters/nfs4_disable_idmapping

Same five users, but the UIDs have been changed a bit.

jratliff is uid 1000
jbail is uid 1001
matt is uid 1003
austin is uid 1002
john is uid 1004

As expected, jratliff and matt can read the private files. jbail and austin cannot. However, neither can john.

So why do jratliff and matt work while john does not? My hypothesis is that the UIDs work out that way.

jratliff has the same UID, so the group membership maps properly. jratliff is a member of ssl-cert on the server, so everything is fine. Matt is also a member of ssl-cert, but this isn't why he can read the files; he can read it because his UID is 1003, which maps to john on the server. User john on the server is a member of ssl-cert, so Matt is become john. In this case, john does not map to anyone on the server, and so he has no permissions. Therefore, john cannot read the private files.

Second hypothesis: Ubuntu 14 is broken.


3) Debian 9 Client

Again, very similar settings. is the IP.
Same five users, but I made one change from the server to the client in UIDs.

jratliff is uid 1000
jbail is uid 1001
matt is uid 3333
austin is uid 2050
john is uid 1003

Again, jratliff can read the private files. jbail and austin cannot. This is expected. I thought matt would be able to read the files, but matt cannot. This seems to be because matt is UID 3333 which means nothing on the server, permissions-wise anyways.

This time, user john can read the private files, which makes sense because he is UID 1003, the same as on the server, and is a member of ssl-cert on the server.

So, Ubuntu 14 seems to work the same as Debian 9, which is expected behavior. It probably isn't broken.


So, is my understand of ID Mapping still flawed? Here's what I see happening:

Client sends UID/GID/GIDs to server in a RPC. Client does not send username or group name strings. I have used wire shark and I cannot find any trace of any user or group name within the transferred between client and server.

Server maps UID sent to local UID. Server ignores secondary GIDs because --manage-gids is set on the server. Server checks permissions against UID, GID, and GIDs on the server attached to the sent UID. If the permissions match, everything goes ahead. IF they do not, permission is denied.

So, I really don't know what id mapping is supposed to do, but it does not appear to be doing what I thought you were telling me it would do. All evidence I had previously gathered to the contrary seems to be the result of coincidence and convergence of UIDs based on my test environment and lack of complete and thorough testing of variables until now.

Thanks for any further insights.


Reply to: