Re: [PATCH 4/7] man/man7/unix.7: SCM_SECURITY: Generalize to other LSMs, not just SELinux

["Günther Noack" <gnoack3000@gmail.com>]

Hello!

On Sat, Oct 31, 2026 at 09:30:34PM +0000, Kuniyuki Iwashima wrote:
> On Sat, 31 Oct 2026 22:06:56 +0100, Günther Noack wrote:
> > On Wed, Oct 28, 2026 at 01:45:11PM +0100, Alejandro Colomar wrote:
> > > > To sum it all up in a table: The only case where the null byte is
> > > > included in the buffer is in SELinux, when the generic SCM layer does
> > > > not need to do truncation:
> > > > 
> > > >                 normal case                truncation case
> > > >   --------------------------------------------------------------
> > > >   SELinux       has trailing null byte     no trailing null byte
> > > >   AppArmor      no trailing null byte      no trailing null byte
> > > >   Smack         no trailing null byte      no trailing null byte
> > > > 
> > > >   (other LSMs don't have the feature at all)
> > > 
> > > Thanks for the table!  This seems to me to be 3 bugs: one in AppArmor,
> > > the same one in Smack, and one in the upper layer which corrupts the
> > > string when truncating.  I wonder if we can do better in the truncation
> > > case, or if it's too late for that.
> > > 
> > > Would you mind CCing the maintainers of the upper layer in
> > > net/core/scm.c?
> > 
> > Adding Eric Dumazet, Paolo Abeni and Willem de Brujin.  (Kuniyuki
> > Iwashima is already in CC.)
> > 
> > Hello maintainers of NETWORKING [SOCKETS]! :)
> > 
> > We are unsure in this documentation review what
> > the intended format of payloads is which are returned by SCM_SECURITY:
> > They have previously been documented as zero-terminated strings (for
> > the SELinux case), but in the case of truncation and in the case of
> > the two other supported LSMs, there implementation does not return a
> > trailing zero byte.
> > 
> > Could you please confirm what the intended interface for SCM_SECURITY
> > is?  The two variants we have been discussing are:
> > 
> > Variant A:
> >   The returned payload is a byte buffer whose contents are defined by
> >   the respective LSM (and which are not necessarily zero-terminated).
> 
> +1, basically each scm data is binary.
> 
> I think it's just man page was not updated for other LSMs.

Thank you for the confirmation, Kuniyuki!

> >   Concrete wording proposal for this variant is in:
> >   https://lore.kernel.org/all/20261027.4df00f962b98@gnoack.org/
      ^ This

Alejandro, in this case, and to make some progress on this patch set,
I'll resend the patch set with the "binary buffer" variant that I
proposed in the other mail.  Let's discuss the wording there, if
needed.

–Günther