Re: [PATCH v8 4/5] proc: Relax check of mount visibility

[Alexey Gladkov <legion@kernel.org>]

On Fri, Apr 10, 2026 at 01:12:36PM +0200, Christian Brauner wrote:
> On Tue, Feb 17, 2026 at 12:59:54PM +0100, Christian Brauner wrote:
> > On Fri, Feb 13, 2026 at 11:44:29AM +0100, Alexey Gladkov wrote:
> > > When /proc is mounted with the subset=pid option, all system files from
> > > the root of the file system are not accessible in userspace. Only
> > > dynamic information about processes is available, which cannot be
> > > hidden with overmount.
> > > 
> > > For this reason, checking for full visibility is not relevant if
> > > mounting is performed with the subset=pid option.
> > > 
> > > Signed-off-by: Alexey Gladkov <legion@kernel.org>
> > > ---
> > >  fs/namespace.c                 | 29 ++++++++++++++++-------------
> > >  fs/proc/root.c                 | 17 ++++++++++-------
> > >  include/linux/fs/super_types.h |  2 ++
> > >  3 files changed, 28 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/fs/namespace.c b/fs/namespace.c
> > > index c58674a20cad..7daa86315c05 100644
> > > --- a/fs/namespace.c
> > > +++ b/fs/namespace.c
> > > @@ -6116,7 +6116,8 @@ static bool mnt_already_visible(struct mnt_namespace *ns,
> > >  		/* This mount is not fully visible if it's root directory
> > >  		 * is not the root directory of the filesystem.
> > >  		 */
> > > -		if (mnt->mnt.mnt_root != mnt->mnt.mnt_sb->s_root)
> > > +		if (!(sb->s_iflags & SB_I_USERNS_ALLOW_REVEALING) &&
> > > +		    mnt->mnt.mnt_root != mnt->mnt.mnt_sb->s_root)
> > >  			continue;
> > >  
> > >  		/* A local view of the mount flags */
> > > @@ -6136,18 +6137,20 @@ static bool mnt_already_visible(struct mnt_namespace *ns,
> > >  		    ((mnt_flags & MNT_ATIME_MASK) != (new_flags & MNT_ATIME_MASK)))
> > >  			continue;
> > 
> > There are a few things that I find problematic here.
> > 
> > Even before your change the mount flags of the first fully visible
> > procfs mount would be picked up. If the caller was unlucky they could
> > stumble upon the most restricted procfs mount in the mount namespace
> > rbtree. Leading to weird scenarios where a user cannot write to the
> > procfs instance they just mounted but could to another one that is also
> > in their namespace.
> > 
> > The other thing is that with this change specifically:
> > 
> >     if (!(sb->s_iflags & SB_I_USERNS_ALLOW_REVEALING) &&
> >         mnt->mnt.mnt_root != mnt->mnt.mnt_sb->s_root)
> > 
> > we start caring about mount options of even partially exposed procfs
> > mounts. IOW, if someone had a bind-mount of e.g., /proc/pressure
> > somewhere that got inherited via CLONE_NEWNS then we suddenly take the
> > mount options of that into account for a new /proc/<pid>/* only instance.
> > I think we should continue caring only about procfs mounts that are
> > visible from their root.
> > 
> > The the other problem is that it is really annoying that we walk all
> > mounts in a mount namespace just to find procfs and sysfs mounts in
> > there. Currently a lot of workloads still do the CLONE_NEWNS dance
> > meaning they inherit all the crap from the host and then proceed to
> > setup their new rootfs. Busy container workloads that can be a lot.
> > 
> > So let's just be honest about it and treat procfs and sysfs as the
> > snowflakes that they have become and record their instances in a
> > separate per mount namespace hlist as in the (untested) patch below [1].
> > 
> > Also SB_I_USERNS_ALLOW_REVEALING seems unnecessary. The only time we
> > care about that flag is when we setup a new superblock. So this could
> > easily be a struct fs_context bitfield that just exists for the duration
> > of the creation of the new superblock and mount. So maybe pass that down
> > to mount_too_revealing() and further down into the actual helper.
> > 
> > [1]:
> > >From 4bbd41e7a3ef91667dd334f31b1b6bf8caec0599 Mon Sep 17 00:00:00 2001
> > From: Christian Brauner <brauner@kernel.org>
> > Date: Tue, 17 Feb 2026 12:02:34 +0100
> > Subject: [PATCH] namespace: record fully visible mounts in list
> > 
> > Instead of wading through all the mounts in the mount namespace rbtree
> > to find fully visible procfs and sysfs mounts, be honest about them
> > being special cruft and record them in a separate per-mount namespace
> > list.
> 
> If you rework this I would expect to take it for v7.3. It's a bit late
> now...

No problem. I understand. Sorry it took me so long to get back to you.
I was laid off from my job and had to look for a new one quickly.

I’ll be back soon to update this patch.

-- 
Rgrds, legion