Unix Domain Socket Credential Support with Connected Trait

[dfreese]

We're using tonic, and want to be able to use it with unix domain sockets. When using them, we want to be able to validate the peer_cred of the tokio::net::UnixStream, for example.

It looks like Request gets it's information from the Connected trait, which is empty in the UDS example

Is peer_cred something that you'd be willing to expose in Request? I understand that would be a little messy, in that it starts to open you up to supporting a number of different connection types through the Request interface.

(BTW: I'm happy to add this, or something else if it seems like there would be a better way of going about it)

[LucioFranco]

If I am miss understanding something, shouldn't this work? https://docs.rs/tonic/0.2.1/tonic/struct.Request.html#method.remote_addr

[dfreese]

So two of the functions UnixStream exposes are peer_cred(&self) which returns tokio::net::unix::UCred and peer_addr(&self) which returns a std::os::unix::net::SocketAddr.

Neither of those are really compatible with std::net::SocketAddr because that expects an IP and a port, but the unix credentials have a user id and group id of the connecting process and the unix socket address is generally a file path.

I could, technically, shoehorn the group id and user id into the flowinfo and scope_id of std::net::SocketAddrV6, since they're u32, but that would be quite the hack isn't what you meant, I assume.

[LucioFranco]

@dfreese ah yeah, socketaddr from net didn't make sense but I forgot to check the module :)

This is an interesting use case that I am not 100% sure how to fix just yet. We might want to coordinate with hyper on this as well.

[abbec]

We also have this use case :) After researching a bit seems to be more blocked by hyper capabilities than tonic atm?

[abbec]

One thought might be to have the ability in the Connected trait to add custom metadata to the connection that is then accessible through the Request?

[abbec]

That way you could associate data from a connection with any Request created from it

[abbec]

Or any way to get back the originally yielded item in the incoming stream. I.e. if incoming is a Stream of UnixListener, we have some way of getting a reference to it from Request. We also have the same problem for Windows NamedPipes. (sorry for monologue)

[dfreese]

Or any way to get back the originally yielded item in the incoming stream. I.e. if incoming is a Stream of UnixListener, we have some way of getting a reference to it from Request.

I like that approach. That would allow for a lot more flexibility for different types of connections. Obviously, I haven't yet had a chance to think about what that'd look like or potential downsides.

[LucioFranco]

Yeah, i think in this case we might want to try to take advantage of https://docs.rs/http/0.2.4/http/request/struct.Request.html#method.extensions?

[LucioFranco]

This should be solved via #255

[davidpdrsn]

@abbec @dfreese I have a possible solution in #647. Do you wanna check it out? Do you think it would fit your use case?

[abbec]

Yeah, looks like what we wanted, currently do not need it anymore but seems useful!

[dfreese]

Thanks @davidpdrsn for getting back to this. That looks like it would certainly fit the use case we had here.