Linux Manual Pages development
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack3000@gmail.com>
To: Alejandro Colomar <alx+linux-man@kernel.org>
Cc: "Kuniyuki Iwashima" <kuniyu@google.com>,
	"Günther Noack" <gnoack3000@gmail.com>,
	linux-man@vger.kernel.org,
	"Michael Kerrisk" <mtk.manpages@gmail.com>,
	"Eric Dumazet" <edumazet@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Willem de Bruijn" <willemb@google.com>
Subject: [PATCH v2 4/8] man/man7/unix.7: SCM_SECURITY: Generalize to other LSMs, not just SELinux
Date: Tue,  3 Nov 2026 21:22:06 +0100	[thread overview]
Message-ID: <20261103202211.13820-5-gnoack3000@gmail.com> (raw)
In-Reply-To: <20261103202211.13820-1-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.

As clarified in [1], the returned security context is in the general
case a byte buffer, not a null-terminated string.  The only LSM that
returns a buffer with trailing null byte is SELinux, but even that is
not guaranteed in case that the message is truncated.

Link: [1] <https://lore.kernel.org/all/auZcwYWv0NeiIR8d@google.com/>
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>
Cc: Eric Dumazet <edumazet@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemb@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.
    
    After confirmation from Kuniyuki Iwashima, this documents it as
    returning a byte buffer.
    
    I prefer this variant over the previous longer one, also because it
    refers to the individual LSMs for the exact format.  A reader of the
    security context will require LSM-specific documentation anyway to
    interpret the security context.
    
    This patch is still LLM-assisted, but at this point, since everything
    is rewritten now, the only LLM-assisted part is the discovery that
    this part of the documentation could be improved.

 man/man7/unix.7 | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/man/man7/unix.7 b/man/man7/unix.7
index 61f06a74359b..c0e2bdbacdd8 100644
--- a/man/man7/unix.7
+++ b/man/man7/unix.7
@@ -312,7 +312,7 @@ .SS Socket options
 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).
@@ -538,13 +538,16 @@ .SS Ancillary messages
 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
-the security context.
-The receiver should allocate at least
-.B NAME_MAX
-bytes in the data portion of the ancillary message for this data.
+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.
+.IP
+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).
 .IP
 To receive the security context, the
 .B SO_PASSSEC
-- 
2.56.0


  parent reply	other threads:[~2026-11-03 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 20:22 [PATCH v2 0/8] unix.7: Socket Options and SCM_* fixes Günther Noack
2026-11-03 20:22 ` [PATCH v2 1/8] man/man7/unix.7: ERRORS: ETOOMANYREFS: Fix the conditions Günther Noack
2026-11-06 13:00   ` Alejandro Colomar
2026-11-03 20:22 ` [PATCH v2 2/8] man/man7/unix.7: Multiple same-typed SCM_* messages may be sent in one message Günther Noack
2026-11-03 20:22 ` [PATCH v2 3/8] man/man7/unix.7: Autobind: Clarify when it happens, and mention SO_PASSPIDFD Günther Noack
2026-11-03 20:22 ` Günther Noack [this message]
2026-11-03 20:22 ` [PATCH v2 5/8] man/man7/unix.7: SO_PASSSEC: wfix Günther Noack
2026-11-03 20:22 ` [PATCH v2 6/8] man/man7/unix.7: Document SO_PASSPIDFD, SO_PEERPIDFD, and SCM_PIDFD Günther Noack
2026-11-03 20:22 ` [PATCH v2 7/8] man/man7/unix.7: Document SO_PASSRIGHTS Günther Noack
2026-11-03 20:22 ` [PATCH v2 8/8] man/man7/unix.7: Remove mentions of "namespace" in the general sense Günther Noack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261103202211.13820-5-gnoack3000@gmail.com \
    --to=gnoack3000@gmail.com \
    --cc=alx+linux-man@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox