Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #188248

Re: NFSv4 without Kerberos and permissions

Show all headers | View raw

On 10/19/2017 8:31 PM, John Ratliff wrote:
> 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
> 

I've decided I will just sync the UIDs and have the server manage groups 
and GIDs.

--John

Back to linux.debian.user | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

NFSv4 without Kerberos and permissions John Ratliff <john@bluemarble.net> - 2017-10-14 21:30 +0200
  Re: NFSv4 without Kerberos and permissions Elena evlt <elenadp.evlt@gmail.com> - 2017-10-14 21:40 +0200
    Re: NFSv4 without Kerberos and permissions John Ratliff <john@bluemarble.net> - 2017-10-15 04:00 +0200
      Re: NFSv4 without Kerberos and permissions Christian Seiler <christian@iwakd.de> - 2017-10-15 09:40 +0200
        Re: NFSv4 without Kerberos and permissions John Ratliff <john@bluemarble.net> - 2017-10-16 20:00 +0200
          Re: NFSv4 without Kerberos and permissions Christian Seiler <christian@iwakd.de> - 2017-10-16 21:40 +0200
            Re: NFSv4 without Kerberos and permissions John Ratliff <john@bluemarble.net> - 2017-10-20 02:40 +0200
              Re: NFSv4 without Kerberos and permissions John Ratliff <john@bluemarble.net> - 2017-10-24 19:30 +0200

csiph-web