On Mon, Feb 23, 2026 at 5:21 PM Paul Moore <[email protected]> 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/[email protected]/ 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 or introduce a new hook in pidfs_init_inode() to determine whether or not to set S_PRIVATE. Such a hook might also handle labeling the pidfs inode although we'd have to see if we have enough information there to do so fully. Note that such an approach will still likely end up leaving pidfs inodes created before initial policy load with the S_PRIVATE flag and hence uncontrolled; not sure if that is a problem in practice. > > diff --git a/fs/pidfs.c b/fs/pidfs.c > index 318253344b5c..4cec73b4cbcf 100644 > --- a/fs/pidfs.c > +++ b/fs/pidfs.c > @@ -921,7 +921,7 @@ static int pidfs_init_inode(struct inode *inode, void > *data) > const struct pid *pid = data; > > inode->i_private = data; > - inode->i_flags |= S_PRIVATE | S_ANON_INODE; > + inode->i_flags |= S_ANON_INODE; > /* We allow to set xattrs. */ > inode->i_flags &= ~S_IMMUTABLE; > inode->i_mode |= S_IRWXU; > > -- > paul-moore.com
