Re: [RFC] mnt_already_visible(): should regular-file mountpoints participate in the visibility check?

On Sat, Aug 08, 2026 at 09:23:09PM +0800, GuLingguang wrote:
> Hi all,
> 
> I have a question about the child-mount check in mnt_already_visible()
> in fs/namespace.c, and I would like to understand the intended
> invariant before proposing anything.
> 
> Background
> 
> The check considers an existing proc mount "not fully visible" when
> it has a locked child mount whose mountpoint is not a permanently
> empty directory:
> 
>         list_for_each_entry(child, &mnt->mnt_mounts, mnt_child) {
>                 struct inode *inode = child->mnt_mountpoint->d_inode;
>                 /* Only worry about locked mounts */
>                 if (!(child->mnt.mnt_flags & MNT_LOCKED))
>                         continue;
>                 /* Is the directory permanently empty? */
>                 if (!is_empty_dir_inode(inode))
>                         goto next;
>         }
> 
> is_empty_dir_inode() returns false for regular files, so a locked
> file mount under /proc (e.g. /proc/uptime) makes the whole proc mount
> "not fully visible", and mounting a fresh proc instance inside a user
> namespace is rejected with EPERM:
> 
>         bwrap: Can't mount proc on /newroot/proc: Operation not permitted
> 
> Real-world impact
> 
> This affects established workloads:
> 
>  * lxcfs (since 2014) overmounts /proc/meminfo and /proc/uptime with
>    FUSE files; lxc reported in March 2016 that this blocked running
>    an unprivileged container inside a privileged one
>    (LKML: "user namespace and fully visible proc and sys mounts").
>  * systemd-nspawn can mask paths under /proc (via --inaccessible=,
>    overmounting them with inaccessible placeholder nodes);
>    flatpak/bwrap inside the container then fails with the EPERM
>    above (systemd issue #34226, still open).
>  * droidspaces virtualizes /proc/uptime and /proc/loadavg the same
>    way today.
>  * Kubernetes works around mount_too_revealing() by mounting proc
>    from an empty pid namespace (noted in the 2025 procfs pidns API
>    series, merge 46582a15c174).
> 
> The invariant
> 
> The check's stated purpose, in Eric Biederman's own words
> (commit 7236c85e1be5), is that fresh mounts of proc and sysfs must
> give the mounter:
> 
>         "no more access to proc and sysfs than if they could have
>          by creating a bind mount"
> 
> The original commit (e51db73532955) phrased it as verifying that
> "the mounted filesystem is not covered in any significant way".
> 
> For a regular-file mountpoint, does a fresh proc mount violate this
> invariant?  It seems not, on three counts:
> 
>  1. Content.  The only thing a fresh mount reveals beyond the covered
>     file is the kernel-generated value of that file, which is already
>     reachable through other means -- e.g. the real uptime is available
>     from /proc/stat's btime and from the uptime(2) syscall, which are
>     not affected by the overmount.  No new information becomes
>     accessible.

It's an information leak. Please trim LLM generated questions to the
bare minimum. We don't have time to read essays the whole day...