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

Daniel Durning danieldurning.work at gmail.com
Fri Feb 20 20:45:00 UTC 2026


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.



More information about the Linux-security-module-archive mailing list