New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for SO_PEERCRED
#4
Comments
Good question. While I think the |
cgwalters
added a commit
to cgwalters/tokio-unix-ipc
that referenced
this issue
Sep 14, 2022
I have several projects that might make use of this crate, and one of them today uses `SO_PEERCRED` to validate the sender's identity. Add basic support for this. I chose to make a small new struct for credentials instead of exposing nix in our public types (perhaps we want to use rustix in the future, etc.) Closes: mitsuhiko#4
cgwalters
added a commit
to cgwalters/tokio-unix-ipc
that referenced
this issue
Sep 14, 2022
I have several projects that might make use of this crate, and one of them today uses `SO_PEERCRED` to validate the sender's identity. Add basic support for this. I chose to make a small new struct for credentials instead of exposing nix in our public types (perhaps we want to use rustix in the future, etc.) Closes: mitsuhiko#4
cgwalters
added a commit
to cgwalters/tokio-unix-ipc
that referenced
this issue
Sep 14, 2022
I have several projects that might make use of this crate, and one of them today uses `SO_PEERCRED` to validate the sender's identity. Add basic support for this. I chose to make a small new struct for credentials instead of exposing nix in our public types (perhaps we want to use rustix in the future, etc.) Closes: mitsuhiko#4
cgwalters
added a commit
to cgwalters/tokio-unix-ipc
that referenced
this issue
Sep 14, 2022
I have several projects that might make use of this crate, and one of them today uses `SO_PEERCRED` to validate the sender's identity. Add basic support for this. I chose to make a small new struct for credentials instead of exposing nix in our public types (perhaps we want to use rustix in the future, etc.) Closes: mitsuhiko#4
cgwalters
added a commit
to cgwalters/tokio-unix-ipc
that referenced
this issue
Sep 14, 2022
I have several projects that might make use of this crate, and one of them today uses `SO_PEERCRED` to validate the sender's identity. Add basic support for this. I chose to make a small new struct for credentials instead of exposing nix in our public types (perhaps we want to use rustix in the future, etc.) Closes: mitsuhiko#4
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In one project I'm using
SO_PEERCRED
: https://github.com/coreos/bootupd/blob/main/src/ipc.rs - looking at using this crate instead. What do you think about exposing that via an API?The usual pattern here is to pass credentials on the first message. In the above code I represented this as a state machine encoded via structs; e.g. perhaps we'd add
RawAuthenticatingSender
andRawUnauthenticatedReceiver
, where e.g.Note this consumes the unauthenticated type and returns credentials. Would need to debate exposing e.g. https://docs.rs/nix/latest/nix/sys/socket/struct.UnixCredentials.html or (probably better for semver) a new struct here.
Alternatively we could add
recv_with_creds()
andsend_with_creds()
to the raw types.The text was updated successfully, but these errors were encountered: