linux-kernel - Re: [PATCH] vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6dd181bf9f6371339a6c31f58f582a9aac3bc36a.camel@kernel.org>
Date: Tue, 03 Feb 2026 11:21:25 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Alexander Mikhalitsyn <alexander@...alicyn.com>
Cc: Trond Myklebust <trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>, 
 Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner
 <brauner@...nel.org>, Jan Kara <jack@...e.cz>,  "Seth Forshee
 (DigitalOcean)"	 <sforshee@...nel.org>, linux-nfs@...r.kernel.org,
 linux-kernel@...r.kernel.org, 	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS

On Tue, 2026-02-03 at 17:11 +0100, Alexander Mikhalitsyn wrote:
> Am Do., 29. Jan. 2026 um 22:48 Uhr schrieb Jeff Layton <jlayton@...nel.org>:
> > 
> > Commit e1c5ae59c0f2 ("fs: don't allow non-init s_user_ns for filesystems
> > without FS_USERNS_MOUNT") prevents the mount of any filesystem inside a
> > container that doesn't have FS_USERNS_MOUNT set.
> > 
> 
> Hi Jeff,
> 
> > This broke NFS mounts in our containerized environment. We have a daemon
> > somewhat like systemd-mountfsd running in the init_ns. A process does a
> > fsopen() inside the container and passes it to the daemon via unix
> > socket.
> > 
> > The daemon then vets that the request is for an allowed NFS server and
> > performs the mount. This now fails because the fc->user_ns is set to the
> > value in the container and NFS doesn't set FS_USERNS_MOUNT.  We don't
> > want to add FS_USERNS_MOUNT to NFS since that would allow the container
> > to mount any NFS server (even malicious ones).
> > 
> > Add a new FS_USERNS_DELEGATABLE flag, and enable it on NFS.
> 
> Great idea, very similar to what we have with BPFFS/BPF Tokens.
> 
> Taking into account this patch, shouldn't we drop FS_USERNS_MOUNT and
> replace it with
> FS_USERNS_DELEGATABLE for bpffs too?
> 
> I mean something like:
> 
> ======================
> $ git diff
> diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> index 9f866a010dad..d8dfdc846bd0 100644
> --- a/kernel/bpf/inode.c
> +++ b/kernel/bpf/inode.c
> @@ -1009,10 +1009,6 @@ static int bpf_fill_super(struct super_block
> *sb, struct fs_context *fc)
>         struct inode *inode;
>         int ret;
> 
> -       /* Mounting an instance of BPF FS requires privileges */
> -       if (fc->user_ns != &init_user_ns && !capable(CAP_SYS_ADMIN))
> -               return -EPERM;
> -
>         ret = simple_fill_super(sb, BPF_FS_MAGIC, bpf_rfiles);
>         if (ret)
>                 return ret;
> @@ -1085,7 +1081,7 @@ static struct file_system_type bpf_fs_type = {
>         .init_fs_context = bpf_init_fs_context,
>         .parameters     = bpf_fs_parameters,
>         .kill_sb        = bpf_kill_super,
> -       .fs_flags       = FS_USERNS_MOUNT,
> +       .fs_flags       = FS_USERNS_DELEGATABLE,
>  };
> 
>  static int __init bpf_init(void)
> ======================
> 
> Because it feels like we were basically implementing this FS_USERNS_DELEGATABLE
> flag implicitly for BPFFS before. I can submit a patch for BPFFS later
> after testing.
> 

Yeah, looks like a good thing to change, since it should have the same
effect. Assuming that works the way it should:

Reviewed-by: Jeff Layton <jlayton@...nel.org>