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

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

On Mon, Oct 26, 2026 at 11:41:13PM +0100, Günther Noack wrote:
> I'm still leaning towards documenting it as a buffer with
> implementation-defined contents which are provided by a LSM.  How
> these buffer contents are interpreted is depending on the LSM in use
> anyway.

To make a more concrete and constructive wording proposal:


SCM_SECURITY

  Receive the security context (the security label) of the peer
  socket, as provided by the active Linux Security Module (LSM).  The
  received ancillary data is a byte buffer.

  The exact format of the security context buffer is defined by the
  active major LSM.  For example, SELinux returns a SELinux label as a
  string (including a terminating null byte).


Does that sound reasonable? Let me know what you think.

I removed the wording "There is no fixed limit ...", because it should
be a given that callers allocate enough buffer space for receiving and
check the truncation flag.  (The more important part is that we remove
the previous wording which suggested that it would fit into NAME_MAX.)

Given that SCM_SECURITY on "real" networks seems to have the same
"buffer, not string" semantics, it feels fair to express it that way?
People who want to read the security context will anyway need to read
up on the exact format used by the LSM in order to attribute any
meaning to it.

–Günther

P.S.: I had a hard time finding many usage examples.  The main user of
SCM_SECURITY seems to be systemd's journald, which uses it to log the
SELinux security label.  That code can deal with both null terminated
strings and ones where it is missing (due to truncation), and there is
a comment indicating that they are aware of possible truncation.