On Tue, 2020-11-10 at 17:43 +0100, Alban Crequy wrote: > Hi, > > I tested the patches on top of 5.10.0-rc3+ and I could mount an NFS > share with a different user namespace. fsopen() is done in the > container namespaces (user, mnt and net namespaces) while fsconfig(), > fsmount() and move_mount() are done on the host namespaces. The mount > on the host is available in the container via mount propagation from > the host mount. > > With this, the files on the NFS server with uid 0 are available in > the > container with uid 0. On the host, they are available with uid > 4294967294 (make_kuid(&init_user_ns, -2)). > Can someone please tell me what is broken with the _current_ design before we start trying to push "fixes" that clearly break it? The current design assumes that the user namespace being used is the one where the mount itself is performed. That means that the uids and gids or usernames and groupnames that go on the wire match the uids and gids of the container in which the mount occurred. The assumption is that the server has authenticated that client as belonging to a domain that it recognises (either through strong RPCSEC_GSS/krb5 authentication, or through weaker matching of IP addresses to a list of acceptable clients). If you go ahead and change the user namespace on the client without going through the mount process again to mount a different super block with a different user namespace, then you will now get the exact same behaviour as if you do that with any other filesystem. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
