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

Alexey Gladkov
2026-04-10T11:31:24Z

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