Re: [PATCH v4 0/2] NFS: Fix interaction between fs_context and user namespaces

[Trond Myklebust <trondmy@hammerspace.com>]

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@hammerspace.com