Hi Günther, > Date: 2026-10-27 09:54:51+0100 > From: Günther Noack > > 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). Let's pause the discussion of the specific text for now. I have questions about the exact format used by each LSM. For example, you say that SELinux guarantees a string. Does it count the '\0' as part of the data size? Or is it guaranteed to exist but not counted? Same question for the other LSMs. Have a lovely night! Alex > 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. --