Bug 201805 - SO_PASSCRED doesn’t state that every message will receive SCM_CREDENTIALS
Summary: SO_PASSCRED doesn’t state that every message will receive SCM_CREDENTIALS
Status: RESOLVED CODE_FIX
Alias: None
Product: Documentation
Classification: Unclassified
Component: man-pages (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: documentation_man-pages@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-28 20:28 UTC by felipe
Modified: 2018-12-23 18:14 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description felipe 2018-11-28 20:28:38 UTC
unix(7) describes SO_PASSCRED and SCM_CREDENTIALS but does not state that every message that a SO_PASSCRED-enabled UNIX socket receives will include SCM_CREDENTIALS, as appears to be the case:
-----
perl -Mautodie -Mstrict -MSocket::MsgHdr -MSocket -e'socketpair my $a, my $b, PF_UNIX, SOCK_STREAM, 0; setsockopt( $b, SOL_SOCKET, SO_PASSCRED, 1 ); syswrite $a, "ab"; my $msg = Socket::MsgHdr->new( buflen => 1, controllen => 96 ); recvmsg($b, $msg) or die $!; printf "got control: %v.02x\n", $msg->control(); recvmsg($b, $msg) or die $!; printf "got control: %v.02x\n", $msg->control();'
-----

strace shows that the relevant system calls here are:

-----
setsockopt(4, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0

write(3, "aa", 2)                       = 2

recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="a", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=14232, uid=1000, gid=1000}}], msg_controllen=32, msg_flags=0}, 0) = 1

recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="b", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=14232, uid=1000, gid=1000}}], msg_controllen=32, msg_flags=0}, 0) = 1
-----

Nothing in the current documentation indicates that SCM_CREDENTIALS is added to every received message; this is a significant detail that should be stated explicitly.

SUGGESTION:

Insert a sentence after SO_PASSCRED’s description’s first sentence, thus:

SO_PASSCRED: Enables the receiving of the credentials of the sending process in an ancillary message. When this option is enabled, all received messages will include SCM_CREDENTIALS as an ancillary message in the msghdr’s control structure, whether the sender sent one or not. When this option is set … <continue with current description>
Comment 1 felipe 2018-11-28 20:29:43 UTC
Sorry … the write() strace call should show "ab", not "aa".
Comment 2 felipe 2018-11-29 12:59:30 UTC
It should also stipulate that the sender’s RUID and RGID are sent in the “default” SCM_CREDENTIALS.

Given the additional information, maybe a new paragraph, then, rather than a single sentence included?

Suggestion:

Note that SO_PASSCRED causes all received messages to include SCM_CREDENTIALS as an ancillary message in the msghdr’s control structure, whether the sender added it or not. If the sender does not send its own SCM_CREDENTIALS, the kernel adds a default that includes the sender’s PID, RUID, and RGID.
Comment 3 Michael Kerrisk 2018-12-21 18:22:52 UTC
Hello Felipe,

Thanks for the report. I reworked the text to day this:

           This socket option enables receipt of  the  credentials  of
           the sending process in an SCM_CREDENTIALS ancillary message
           in each subsequently message.  The returned credentials are
           those  specified  by the sender using SCM_CREDENTIALS, or a
           default that includes the sender's PID, real user  ID,  and
           real  group  ID,  if the sender did not specify SCM_CREDEN‐
           TIALS ancillary data.

Thanks,

Michael
Comment 4 felipe 2018-12-21 19:29:50 UTC
Hi Michael,

Two small suggestions, if I may?

1) “subsequent” rather than “subsequently”?

2) Maybe “causes” rather than “enabled”? It seems to imply more strongly that the SCM_CREDENTIALS are received each time, no matter what the sender does. (Granted, the rest of the paragraph makes that clear, but just in case someone skims and stops after the first sentence.)


Thank you very much!
Comment 5 Michael Kerrisk 2018-12-23 18:14:02 UTC
Hello Felipe,

[I caught this note of yours only by chance; really, you need to reopen the bug if you want me to see new commets.]

(In reply to felipe from comment #4)
> Hi Michael,
> 
> Two small suggestions, if I may?
> 
> 1) “subsequent” rather than “subsequently”?

Actually, I meant to say "subsequently received". Fixed now.

> 2) Maybe “causes” rather than “enabled”? It seems to imply more strongly
> that the SCM_CREDENTIALS are received each time, no matter what the sender
> does. (Granted, the rest of the paragraph makes that clear, but just in case
> someone skims and stops after the first sentence.)

I agree. Fixed.

Thanks,

Michael

PS The Changes are now pushed to git

Note You need to log in before you can comment on or make changes to this bug.