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
/etc/hosts.allow
ALL: ALL
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 10.9.111.1/16
/etc/exports is
/srv/nfs4 10.9.0.0/16(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs4/ssl 10.9.0.0/16(rw,sync,no_subtree_check)
/srv/nfs4/ssl/wildcard 10.9.0.0/16(ro,sync,no_subtree_check)
I have set nfs_disable_idmapping to 0
$ cat /sys/module/nfsd/parameters/nfs4_disable_idmapping
N
This is my /srv/nfs4 file structure:
$ ls -lR /srv/nfs4
/srv/nfs4:
total 4
drwxr-sr-x 3 root ssl-cert 4096 Oct 19 20:01 ssl
/srv/nfs4/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
/srv/nfs4/ssl/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
(10.9.111.2/16).
I removed nfs4_disable_idmapping in both the nfsd and nfs modules.
$ cat /sys/module/nfsd/parameters/nfs4_disable_idmapping
N
$ cat /sys/module/nfs/parameters/nfs4_disable_idmapping
N
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. 10.9.111.3/16 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.
--John