Peer credentials on Unix socket

60d5366
Opened by Martin Habovštiak at 2025-02-03 14:02:12

https://github.com/tokio-rs/tokio-uds/pull/13 was recently merged, so I'd like to open an issue of adding same thing to stdlib. TL;DR It allows one to get effective UID and GID of the process which created the remote socket.

I suggest to test it with Tokio now and when there is consensus, we can merge similar change. I need this function, so I'm going to test it anyway.

  1. Considering that newtypes for pid_t, uid_t and gid_t landed in nix, we shoul consider using same newtypes in std and then simply reexport them in nix.

    Martin Habovštiak at 2017-07-11 18:51:06

  2. This seems like a reasonable addition. It looks like there are some extra platforms that require special handling though - Solaris and FreeBSD: https://doxygen.postgresql.org/getpeereid_8c_source.html

    Steven Fackler at 2017-07-11 19:45:12

  3. The implementation in tokio handles Linux and FreeBSD (incl. macOS). I doesn't handle Solaris because I don't have Solaris machine.

    Martin Habovštiak at 2017-07-11 20:05:14

  4. This isn't my area of expertise but I would be interested to see an API proposed for this in a PR.

    David Tolnay at 2017-11-19 00:27:27

  5. Hi guys. We're quite keen for something like this in the stdlib. The implementation in the Tokio repository looks good to me, and from a cursory glance it looks like the stdlib can be very similar. I'm happy to give this a crack -- should I submit an RFC first or is a normal code pull request OK? 😄

    Cheers! 🙂

    Joe Ellis at 2020-07-28 14:06:12

  6. The PR which implements this issue is ready for review 🚀 #75148

    Hugues de Valon at 2020-08-28 09:39:18

  7. Since the PR was merged should the labels (and perhaps also the title) be updated to tracking issue?

    Martin Habovštiak at 2020-09-16 10:05:14

  8. I would agree with that! I guess the steps to follow for stabilization are here?

    Hugues de Valon at 2020-09-16 10:13:25

  9. I noticed that #75148 doesn't include the PID on macOS/iOS, presumably because it uses getpeereid. However, macOS/iOS do provide LOCAL_PEERPID, which can be used with getsockopt to get just the peer's PID. Would anybody be opposed to a follow-up PR that adds support via LOCAL_PEERPID on macOS?

    William Woodruff at 2020-11-24 15:43:35

  10. Yeah, I don't see a reason to not do that. It'd be nice to document which platforms support it.

    Martin Habovštiak at 2020-11-24 19:31:10

  11. Yeah, I don't see a reason to not do that. It'd be nice to document which platforms support it.

    Sounds good! I've opened #79387. And yeah, documentation for these across the different Unices can be difficult to find:

    • OpenBSD appears to support SO_PEERCRED with a structure definition that's identical to Linux's ucred: https://github.com/openbsd/src/blob/0e2efb92954da6bfe2c3ee0a27e3261f42d5f339/sys/sys/socket.h#L300

    • FreeBSD supports LOCAL_PEERCRED with a xucred ("extended" ucred?) structure that includes a PID: https://github.com/freebsd/freebsd/blob/b7a3cee9e0227e0787cbfb3408d6a3ec26d1ac86/sys/sys/ucred.h#L98

    • NetBSD supports LOCAL_PEEREID like macOS, but actually includes the PID: https://man.netbsd.org/unix.4

    William Woodruff at 2020-11-24 19:53:50

  12. The cr_pid on FreeBSD was added somewhat recently and is only available in FreeBSD 13 which is not released yet. The man page for FreeBSD 12 doesn't mention it.

    The uds crate can be used to get peer credentials for blocking sockets on stable.

    Torbjørn Birch Moltu at 2020-11-24 20:26:43

  13. I write which platforms std supports in its doc comment.

    Martin Habovštiak at 2020-11-24 20:53:57

  14. With https://github.com/rust-lang/rust/pull/69864 merged there are now two very similar types: UCred and SocketCred. Can these two types be combined into one?

    Dominik Stolz at 2020-12-08 15:50:37

  15. With #69864 merged there are now two very similar types: UCred and SocketCred. Can these two types be combined into one?

    Potentially? Looking at the current code, the two currently perform slightly different functions: UCred (which I think is badly named, more on that below) is used in a somewhat platform agnostic way to get the peer credentials associated with a domain socket client, while SocketCred seems to be associated with ancillary data mechanisms that I'm not 100% clear on (I've never touched them at all).

    IMO, it makes sense to rename UCred to PeerCred (since struct ucred is a non-POSIX implementation detail and we're only using it in a peer credential context) and to unify it with SocketCred, if possible. I'm not sure about the latter, since it means changing Option<pid_t> to a standalone pid_t, and I'm not sure if all (Unixy) OSes support getting a peer's PID.

    William Woodruff at 2020-12-08 18:24:28

  16. I'm not sure if all (Unixy) OSes support getting a peer's PID.

    They don't, that's the reason there's Option in the first place. The structs seem to be sufficiently different to be different types but I may be missing something.

    Martin Habovštiak at 2020-12-08 18:48:32

  17. They don't, that's the reason there's Option in the first place.

    I'm not sure if it's 100% of Unices, but I think almost all of them support some mechanism for getting the peer's PID. It's just not through struct ucred, hence my comment about UCred being a misleading wrapper.

    For example, macOS doesn't have a PID in its struct ucred, but it does support getting the peer's PID through the LOCAL_PEERPID sockopt. All of the BSDs expose similar mechanisms.

    William Woodruff at 2020-12-08 20:55:03

  18. UCred being a misleading wrapper.

    Sure, I agree with renaming.

    but it does support getting the peer's PID through the LOCAL_PEERPID sockopt.

    Yes, this is implemented. :)

    All of the BSDs expose similar mechanisms.

    A PR would be nice if you happen to have some experience with this. Shouldn't be big, most of the stuff is already there.

    Martin Habovštiak at 2020-12-08 21:11:15

  19. A PR would be nice if you happen to have some experience with this. Shouldn't be big, most of the stuff is already there.

    I can definitely try! I have #79387 open for macOS right now, and I'll try to get some similar ones in the pipeline for the BSDs.

    William Woodruff at 2020-12-08 21:51:14

  20. What is the current status of this feature peer_credentials_unix_socket graduating to stable? I was surprised to find this issue is 5 years old. It's a great feature but it sucks having to be on nightly to get it!

    Mark Solters at 2022-10-21 14:38:08

  21. Looks like there were at least no complaints about it apart from UCred being misleading name. Looking at the docs the struct description could use some polishing. Maybe open an ACP? If you have some experience with using it on nightly that should help. I changed my interests over time and don't have it.

    Martin Habovštiak at 2022-10-21 17:31:51

  22. I'm happy to help with the stabilization here as well.

    @msolters: if you do an ACP for renaming UCred, I'd suggest PeerCred (per https://github.com/rust-lang/rust/issues/42839#issuecomment-740820027). Otherwise, I can do the ACP and from there begin the stabilization process (at least the outsider bits).

    William Woodruff at 2022-12-29 01:39:41

  23. Is there any chance of this being stabilized anytime soon? I'm using this feature in a project, and I'd like to be able to back down to rust-stable.

    Eric McCorkle at 2024-12-13 11:47:04

  24. I'm interested in this feature, but I realized I'd be more interested in pidfd to avoid pid reuse issues. It wasn't available at the time this issue was created but it appears that linux now supports SO_PEERPIDFD https://github.com/torvalds/linux/commit/ba47545c756b55f4b114c45fea7d52dd1577e181 . Would it be reasonable to tack that on here, or are there use cases for pid that aren't better served by pidfd?

    Andrew Baxter at 2025-02-03 13:44:40

  25. @andrewbaxter that'd require the struct to not be Copy, so I think it'd be better to just provide a separate method. (Also because the method is Linux-only anyway.) BTW great to hear that Linux devs are fixing those races! Shame it's just Linux.

    Martin Habovštiak at 2025-02-03 14:02:12