set_security_override_from_ctx()

set_security_override_from_ctx()

[Casey Schaufler]

While trying to ensure sanity in security context processing I
discovered set_security_override_from_ctx(), which is not used anywhere
in the upstream kernel. Does anyone here know what its purpose is? I
would very much like to remove it, but of course wouldn't want to break
anything important.

Re: set_security_override_from_ctx()

[Casey Schaufler]

Adding David, who wrote the code ...

On 12/3/2025 1:32 PM, Casey Schaufler wrote:
> While trying to ensure sanity in security context processing I
> discovered set_security_override_from_ctx(), which is not used anywhere
> in the upstream kernel. Does anyone here know what its purpose is? I
> would very much like to remove it, but of course wouldn't want to break
> anything important.
>
>

Re: set_security_override_from_ctx()

[Paul Moore]

On Wed, Dec 3, 2025 at 5:03 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Adding David, who wrote the code ...
>
> On 12/3/2025 1:32 PM, Casey Schaufler wrote:
> > While trying to ensure sanity in security context processing I
> > discovered set_security_override_from_ctx(), which is not used anywhere
> > in the upstream kernel. Does anyone here know what its purpose is? I
> > would very much like to remove it, but of course wouldn't want to break
> > anything important.

It looks like set_security_override_from_ctx() was first introduced
back in v2.6.29, but I didn't see an in-tree caller until v2.6.30.  I
didn't check every kernel release, but doing some spot checks it looks
like cachefiles remained the only user until it dropped the call in
v6.12 with the following commit:

  commit e5a8b6446c0d370716f193771ccacf3260a57534
  Author: Max Kellermann <max.kellermann@ionos.com>
  Date:   Fri Dec 13 13:50:05 2024 +0000

   cachefiles: Parse the "secctx" immediately

   Instead of storing an opaque string, call security_secctx_to_secid()
   right in the "secctx" command handler and store only the numeric
   "secid".  This eliminates an unnecessary string allocation and allows
   the daemon to receive errors when writing the "secctx" command instead
   of postponing the error to the "bind" command handler.  For example,
   if the kernel was built without `CONFIG_SECURITY`, "bind" will return
   `EOPNOTSUPP`, but the daemon doesn't know why.  With this patch, the
   "secctx" will instead return `EOPNOTSUPP` which is the right context
   for this error.

   This patch adds a boolean flag `have_secid` because I'm not sure if we
   can safely assume that zero is the special secid value for "not set".
   This appears to be true for SELinux, Smack and AppArmor, but since
   this attribute is not documented, I'm unable to derive a stable
   guarantee for that.

   Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
   Signed-off-by: David Howells <dhowells@redhat.com>
   Link: https://lore.kernel.org/r/20241209141554.638708-1-max.kellermann@ionos
.com/
   Link: https://lore.kernel.org/r/20241213135013.2964079-6-dhowells@redhat.com
   Signed-off-by: Christian Brauner <brauner@kernel.org>

... which basically just drops the security_secctx_to_secid() from the
code path.

I would suggest sending a patch to remove
set_security_override_from_ctx() since there are no longer any
callers.  Send it to the LSM list and I'll merge it once the merge
window closes.

-- 
paul-moore.com

Re: set_security_override_from_ctx()

[David Howells]

Paul Moore <paul@paul-moore.com> wrote:

> I would suggest sending a patch to remove
> set_security_override_from_ctx() since there are no longer any
> callers.  Send it to the LSM list and I'll merge it once the merge
> window closes.

Fine by me.

David