Open
Description
tokio-rs/tokio-uds#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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
Kixunil commentedon Jul 11, 2017
Considering that newtypes for
pid_t,uid_tandgid_tlanded innix, we shoul consider using same newtypes instdand then simply reexport them innix.sfackler commentedon Jul 11, 2017
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
Kixunil commentedon Jul 11, 2017
The implementation in
tokiohandles Linux and FreeBSD (incl. macOS). I doesn't handle Solaris because I don't have Solaris machine.dtolnay commentedon Nov 19, 2017
This isn't my area of expertise but I would be interested to see an API proposed for this in a PR.
joechrisellis commentedon Jul 28, 2020
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! 🙂
hug-dev commentedon Aug 28, 2020
The PR which implements this issue is ready for review 🚀
#75148
Kixunil commentedon Sep 16, 2020
Since the PR was merged should the labels (and perhaps also the title) be updated to tracking issue?
hug-dev commentedon Sep 16, 2020
I would agree with that!
I guess the steps to follow for stabilization are here?
11 remaining items
Kixunil commentedon Dec 8, 2020
They don't, that's the reason there's
Optionin the first place. The structs seem to be sufficiently different to be different types but I may be missing something.woodruffw commentedon Dec 8, 2020
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 aboutUCredbeing 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 theLOCAL_PEERPIDsockopt. All of the BSDs expose similar mechanisms.Kixunil commentedon Dec 8, 2020
Sure, I agree with renaming.
Yes, this is implemented. :)
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.
woodruffw commentedon Dec 8, 2020
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.
Auto merge of rust-lang#79387 - woodruffw-forks:ww/peer-cred-pid-maco…
msolters commentedon Oct 21, 2022
What is the current status of this feature
peer_credentials_unix_socketgraduating tostable? 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!
Kixunil commentedon Oct 21, 2022
Looks like there were at least no complaints about it apart from
UCredbeing 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.woodruffw commentedon Dec 29, 2022
I'm happy to help with the stabilization here as well.
@msolters: if you do an ACP for renaming
UCred, I'd suggestPeerCred(per #42839 (comment)). Otherwise, I can do the ACP and from there begin the stabilization process (at least the outsider bits).std::os::unix::ucredmodule private #122147Rollup merge of rust-lang#122147 - kadiwa4:private_impl_mods, r=worki…
Unrolled build for rust-lang#122147
rust/sim: Remove dependency on nightly Rust
emc2 commentedon Dec 13, 2024
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.
andrewbaxter commentedon Feb 3, 2025
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_PEERPIDFDtorvalds/linux@ba47545 . Would it be reasonable to tack that on here, or are there use cases for pid that aren't better served by pidfd?Kixunil commentedon Feb 3, 2025
@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.