[PATCH v3] memfd,selinux: call security_inode_init_security_anon

Paul Moore paul at paul-moore.com
Mon Oct 13 16:11:26 UTC 2025


On Mon, Sep 22, 2025 at 3:30 PM Paul Moore <paul at paul-moore.com> wrote:
> On Mon, Sep 22, 2025 at 9:12 AM Stephen Smalley
> <stephen.smalley.work at gmail.com> wrote:
> >
> > When would you recommend that I re-apply the corresponding userspace
> > patch to reserve this policy capability number for memfd_class?
> > After it is moved to selinux/dev? Understand that it isn't truly
> > reserved until it lands in a kernel.org kernel but would prefer to
> > reapply it sooner than that since there may be other policy capability
> > requests queueing up (e.g. bpf token) that should be done relative to
> > it. Can always revert it again if necessary, at least until another
> > userspace release is made (not sure on timeline for that).
>
> When it comes to API issues like this, my standard answer is "tagged
> release from Linus" as it is the safest option, but you know that
> already.
>
> The fuzzier answer is that unless something crazy happens, I'm likely
> going to move the patches, in order, from selinux/dev-staging into
> selinux/dev when the merge window closes.  This means that any
> policycap API additions for the next cycle are going to start with the
> memfd_class policycap, so it *should* be fairly safe to merge the
> userspace bits now, I just wouldn't do a userspace release with that
> API change until we see a tagged release from Linus.

... and the patch is now in selinux/dev, thanks everyone!

-- 
paul-moore.com



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