[RFC PATCH] fs/pidfs: Add permission check to pidfd_info()

[Christian Brauner]

On Fri, Feb 20, 2026 at 03:45:00PM -0500, Daniel Durning wrote:
> On Tue, Feb 17, 2026 at 7:01 AM Christian Brauner <brauner at kernel.org> wrote:
> >
> > On Wed, Feb 11, 2026 at 02:43:21PM -0500, Daniel Durning wrote:
> > > On Mon, Feb 9, 2026 at 9:01 AM Christian Brauner <brauner at kernel.org> wrote:
> > > >
> > > > On Fri, Feb 06, 2026 at 06:02:48PM +0000, danieldurning.work at gmail.com wrote:
> > > > > From: Daniel Durning <danieldurning.work at gmail.com>
> > > > >
> > > > > Added a permission check to pidfd_info(). Originally, process info
> > > > > could be retrieved with a pidfd even if proc was mounted with hidepid
> > > > > enabled, allowing pidfds to be used to bypass those protections. We
> > > > > now call ptrace_may_access() to perform some DAC checking as well
> > > > > as call the appropriate LSM hook.
> > > > >
> > > > > The downside to this approach is that there are now more restrictions
> > > > > on accessing this info from a pidfd than when just using proc (without
> > > > > hidepid). I am open to suggestions if anyone can think of a better way
> > > > > to handle this.
> > > >
> > > > This isn't really workable since this would regress userspace quite a
> > > > bit. I think we need a different approach. I've given it some thought
> > > > and everything's kinda ugly but this might work.
> > > >
> > > > In struct pid_namespace record whether anyone ever mounted a procfs
> > > > with hidepid turned on for this pidns. In pidfd_info() we check whether
> > > > hidepid was ever turned on. If it wasn't we're done and can just return
> > > > the info. This will be the common case. If hidepid was ever turned on
> > > > use kern_path("/proc") to lookup procfs. If not found check
> > > > ptrace_may_access() to decide whether to return the info or not. If
> > > > /proc is found check it's hidepid settings and make a decision based on
> > > > that.
> > > >
> > > > You can probably reorder this to call ptrace_may_access() first and then
> > > > do the procfs lookup dance. Thoughts?
> > >
> > > Thanks for the feedback. I think your solution makes sense.
> > >
> > > Unfortunately, it seems like systemd mounts procfs with hidepid enabled on
> > > boot for services with the ProtectProc option enabled. This means that
> > > procfs will always have been mounted with hidepid in the init pid namespace.
> > > Do you think it would be viable to record whether or not procfs was mounted
> > > with hidepid enabled in the mount namespace instead?
> >
> > I guess we can see what it looks like.
> 
> Having looked into this some more I am not sure if the mount
> namespace is viable either since a single proc instance could be in
> multiple mount namespaces. In addition the mount namespace
> does not seem to be easily accessible in the function where proc
> mount options are applied. I also considered adding an option
> similar to hidepid to pidfs, but since pidfs is not userspace-mounted
> I do not think that is possible without some significant changes.
> 
> Doing a proc lookup with kern_path() does work, but it does not seem
> practical in terms of performance unless we had some other way to
> skip it in the common case.
> 
> Curious if anyone else has any ideas or suggestions on how this
> could be implemented.

Ok, so there's another series that adds support for allowing to mount
procfs with subset=pid. That series currently uses an arcane mechanism
where it walks all mounts in the caller mounts namespace to find procfs
mounts and check its mount options (mount_too_revealing()). To get away
from this barbaric hack I proposed recording all fully visible procfs
mounts in a separate list on struct mnt_namespace that it can walk
whenever a new procfs mount gets plugged in. Once we've done that work
we effectively track whenever a procfs mount comes and goes from a given
mount namespace. When we plug in that mount we simply remember the
option used for the least restrictive procfs mount in that namespace in
a per-mntns "proc_visiblity" field or something.

Then in pidfs we simply do a:

visibility_restricted = READ_ONCE(current->ns_proxy->mnt_ns);

and be done with it. No locks, no lookup, no perf hit. Thoughts?