From: Paul Moore <paul@paul-moore.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: "Thiébaud Weksteen" <tweek@google.com>,
"Hugh Dickins" <hughd@google.com>,
"James Morris" <jmorris@namei.org>,
"Jeff Vander Stoep" <jeffv@google.com>,
"Nick Kralevich" <nnk@google.com>, "Jeff Xu" <jeffxu@google.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Isaac Manjarres" <isaacmanjarres@google.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3] memfd,selinux: call security_inode_init_security_anon
Date: Mon, 22 Sep 2025 15:30:04 -0400 [thread overview]
Message-ID: <CAHC9VhS2TU2GWgfUOHerbfjyxb5QZMSMqLdQirjSdkUohR7opg@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ5GidA9oT_fbKRe_nH1J3mER0ggM-dBW=Nuo765JDuQKg@mail.gmail.com>
On Mon, Sep 22, 2025 at 9:12 AM Stephen Smalley
<stephen.smalley.work@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.
--
paul-moore.com
next prev parent reply other threads:[~2025-09-22 19:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 2:04 Thiébaud Weksteen
2025-09-18 13:21 ` Stephen Smalley
2025-09-21 18:31 ` Paul Moore
2025-09-22 3:23 ` Hugh Dickins
2025-09-22 13:12 ` Stephen Smalley
2025-09-22 19:30 ` Paul Moore [this message]
2025-10-13 16:11 ` Paul Moore
2025-10-13 22:19 ` Thiébaud Weksteen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHC9VhS2TU2GWgfUOHerbfjyxb5QZMSMqLdQirjSdkUohR7opg@mail.gmail.com \
--to=paul@paul-moore.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=hughd@google.com \
--cc=isaacmanjarres@google.com \
--cc=jeffv@google.com \
--cc=jeffxu@google.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nnk@google.com \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=tweek@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox