[PATCH] lsm: move inode IS_PRIVATE checks to individual LSMs

Paul Moore paul at paul-moore.com
Tue Feb 24 19:12:38 UTC 2026


On Tue, Feb 24, 2026 at 9:44 AM Stephen Smalley
<stephen.smalley.work at gmail.com> wrote:
> On Mon, Feb 23, 2026 at 5:21 PM Paul Moore <paul at paul-moore.com> wrote:
> > I'm not going to argue with that, and perhaps that is a good next
> > step: send a quick RFC patch to the VFS folks, with the LSM list CC'd,
> > that drops setting the S_PRIVATE flag to see if they complain too
> > loudly.  Based on other threads, Christian is aware that we are
> > starting to look at better/proper handling of pidfds/pidfs so he may
> > be open to dropping S_PRIVATE since it doesn't really have much impact
> > outside of the LSM, but who knows; the VFS folks have been growing a
> > bit more anti-LSM as of late.
>
> Adding S_PRIVATE to pidfs inodes was originally motivated by this bug report:
> https://lore.kernel.org/linux-fsdevel/20240222190334.GA412503@dev-arch.thelio-3990X/
> when pidfs was first introduced as its own distinct filesystem type.
> Otherwise, Fedora (and likely any other system enforcing SELinux)
> stopped working.
> So we can't unconditionally remove S_PRIVATE from pidfs inodes without breaking
> existing userspace/policy. If we want to introduce controls over pidfs
> inodes and do so in a
> backward-compatible manner, we have to either move the S_PRIVATE
> handling into the
> individual LSMs ...

... just like was originally proposed.  Just do that and be done with
it; back-n-forth like this just wastes time and energy.

-- 
paul-moore.com



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