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

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3710 bytes --]

Hi Günther,

> Date: 2026-10-21 23:22:53+0200
> From: Günther Noack <gnoack3000@gmail.com>
>
> Reword the description of SCM_SECURITY to not be specific to SELinux.
> 
> The security context is populated in scm_passec() in linux.git
> net/core/scm.c, through the security_secid_to_secctx() LSM hook, which
> is currently implemented by SELinux, Smack and AppArmor.
> 
> Also clarify the properties of the returned string:
> 
> * There is no NAME_MAX limit on the length; SELinux contexts can be
>   longer than that.  If the control buffer is too small, put_cmsg()
>   truncates the data and sets MSG_CTRUNC.
> 
> * Whether the string is null-terminated also depends on the LSM:
>   SELinux includes the null byte in the length, but smack_to_secctx()
>   in security/smack/smack_lsm.c uses strlen() and doesn't.

...

> Fixes: ffad6a017f91 (2018-07-28; "unix.7: Document SCM_SECURITY ancillary data")
> Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> Cc: Kuniyuki Iwashima <kuniyu@google.com>
> Assisted-by: LLM
> Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> ---
> 
> Notes:
>     This feature is also available in other LSMs.  Unfortunately, they
>     implemented it inconsistently and that complicates the description of
>     how string boundaries are handled.  Linux does indeed neither
>     guarantee that this terminates with a NUL byte, nor that NAME_MAX is
>     large enough to hold it.

...

>     
>     This is the verbose variant, but I am open for suggestions regarding
>     what level of detail is appropriate here.
> 
>  man/man7/unix.7 | 25 +++++++++++++++++++------
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/man/man7/unix.7 b/man/man7/unix.7
> index ded82768322b..4abd216d19c7 100644
> --- a/man/man7/unix.7
> +++ b/man/man7/unix.7
> @@ -317,7 +317,7 @@ and returned as the result of
>  is an integer boolean flag.
>  .TP
>  .B SO_PASSSEC
> -Enables receiving of the SELinux security label of the peer socket
> +Enables receiving of the security label of the peer socket
>  in an ancillary message of type
>  .B SCM_SECURITY
>  (see below).
> @@ -544,13 +544,26 @@ message, the
>  option must be enabled on the socket.
>  .TP
>  .B SCM_SECURITY
> -Receive the SELinux security context (the security label)
> -of the peer socket.
> -The received ancillary data is a null-terminated string containing
> +Receive the security context (the security label)
> +of the peer socket,
> +as provided by the active Linux Security Module (LSM),
> +such as SELinux or Smack.
> +The received ancillary data is a string containing
>  the security context.
> -The receiver should allocate at least
> +Whether the string includes a terminating null byte
> +depends on the LSM;

This seems to contradict the commit message.  The commit message says
that the string is terminated, but that the reported length might or
might not be off-by-one (i.e., not count or count the '\0').

This text, however, is saying that in some cases there might not be
a '\0' at all.

Am I missing something?


Have a lovely day!
Alex

> +the length of the data is given by the
> +.I cmsg_len
> +field.
> +There is no fixed limit on the length of the security context;
> +allocating
>  .B NAME_MAX
> -bytes in the data portion of the ancillary message for this data.
> +bytes in the data portion of the ancillary message
> +is usually enough.
> +If the buffer is too small,
> +the data is truncated and the
> +.B MSG_CTRUNC
> +flag is set (see below).
>  .IP
>  To receive the security context, the
>  .B SO_PASSSEC
> -- 
> 2.56.0
> 
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]