The curious case of pidfs and pidfds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Late last year Chris sent an email[0] about the increasing use of
pidfds on modern systems and the difficulty in distinguishing between
pidfds and other file descriptors when passing or inheriting fds
across a process boundary.  A few months later there was a similar and
very brief discussion on a related GitHub PR[1] to add some basic
enablement in refpol.  Unfortunately both discussions faded without
much in the way of resolution and I'm concerned that we don't have a
(good) plan for handling pidfds.

As we are starting to see pidfds become more common (which I view as
an overall positive), the lack of a good way to handle pidfds is
becoming more of an issue.  Having just started to look at some of the
kernel code a couple of hours ago (see fs/pidfs.c) I'm worried that
many of the access controls we have for /proc/PID may be missing or
bypassed with pidfds and their associated inodes.  I haven't spent a
lot of time on this just yet, and with the upcoming holidays it isn't
clear how far I'll get before the end of the year, but I wanted to
send out another email on this topic to see if anyone else has spent
any time looking at pidfds and pidfs.

Anyone?

[0] https://lore.kernel.org/selinux/da1d9efd-fdc1-4651-8a7a-30ae4a399926@xxxxxxxxxxxxxxxxxxx
[1] https://github.com/SELinuxProject/refpolicy/pull/762

-- 
paul-moore.com




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux