`man 7 unix` states: ``` SO_PEERCRED This read-only socket option returns the credentials of the peer process connected to this socket. The returned credentials are those that were in effect at the time of the call to connect(2) or socketpair(2). ``` This doesn't match real behavior in following situation (just an example): - process starts with uid=0, gid=0 - process creates UNIX socket, binds it, listens on it - process changes to uid=uid1, git=gid1 (using `setresuid()`, `setresgid()`) - another process connects to listening socket and requests peer's credentials using `getsockopt(... SOL_SOCKET, SO_PEERCRED ...)` Reproducible: Always Actual Results: Actual result: SO_PEERCRED reports (0, 0) Expected Results: Expectation according to the man page: SO_PEERCRED reports (uid1, gid1), because peer process was running under (uid1, gid1) "at the time of the call to connect(2)" Take a note, I think actual behavior makes sense, and it's a man page what needs update.
Could you show us your reproducer? Does it involve SOCK_STREAM or SOCK_DGRAM sockets?
(In reply to Florian Weimer from comment #1) > Does it involve SOCK_STREAM or SOCK_DGRAM sockets? `socket(AF_UNIX, SOCK_STREAM, 0)`
Complete reproducer, please.
(In reply to Florian Weimer from comment #3) > Complete reproducer, please. Sure, I was just extracting minimal example from the code - attached now. Console output - client side: ``` $ ls -la socket srw-rw-rw-. 1 root root 0 Nov 17 13:30 socket $ ./client fd = 3 Peer's pid = 1226941, uid = 0, gid = 0 $ cat /proc/1226941/status | grep Uid Uid: 1000 1000 1000 1000 $ cat /proc/1226941/status | grep Gid Gid: 1000 1000 1000 1000 ``` Console output - server side: ``` # ./server Peer's pid = 1227027, uid = 1000, gid = 1000 ```
Could we make the reproducer public? As far as I can tell, the relevant socket is created after the UID change, during the accept system call. So I think the wording in the manual page is correct?
(In reply to Florian Weimer from comment #7) > Could we make the reproducer public? Sure. > As far as I can tell, the relevant socket is created after the UID change, Right: after process with listening socket changes uid/gid to 1000. > during the accept system call. `connect()` on client side and `accept()` on server side. > So I think the wording in the manual page is correct? Why? ``` The returned credentials are those that were in effect at the time of the call to connect(2) or socketpair(2). ``` At the time of `connect()` peer runs under (1000, 1000), but SO_PEERCRED returns (0, 0)
Huh, you right. So yes, the manual page should be clarified. Thanks.
Hi, thanks for the report, I've been looking at the comments, but as I'm not a heavy user of the sockets, I don't want to mess up the man-page entry. Do you have some recommendations for the change, that would describe the actual behavior, so I can change it and also propose it to upstream as we focus on upstream first? Thank you so much for the help
(In reply to Lukas Javorsky from comment #10) > Hi, thanks for the report, > > I've been looking at the comments, but as I'm not a heavy user of the > sockets, I don't want to mess up the man-page entry. > > Do you have some recommendations for the change, that would describe the > actual behavior, so I can change it and also propose it to upstream as we > focus on upstream first? To be honest, I'm not even completely sure what is wrong: a man page or 'SO_PEERCRED' actual behavior (but tend to think that the former). Is it possible to open an upstream ticket?
Yes, it's possible to create an issue, you can follow these steps: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING#n212 If you don't want to do it, I can do it for you just let me know.
https://lore.kernel.org/linux-man/CABPeg3a9L0142gmdZZ+0hoD+Q3Vgv0BQ21g8Z+gf2kznWouErA@mail.gmail.com/T/#u
Man page fix: https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=b34c2340657cfe467a0c2cde4933422bddf4348b
Thanks, backported: https://src.fedoraproject.org/rpms/man-pages/c/e91fe293d715a07632b274942c2adc5dfb906f88
FEDORA-2023-f52730a91d has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f52730a91d
FEDORA-2023-f52730a91d has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f52730a91d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f52730a91d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-f52730a91d has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.