Add LocalChannelCredentials and LocalServerCredentials, with UDS support
- Dominant language
- Java
- Stars
- 12.1k
- Forks
- 4k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 37
Description
Using version gRPC 1.52.1
When looking at the transport attributes, from a ServerInterceptor, on a Netty Server, with a KQueue (or Epoll) channel, I see the following:
```
{io.grpc.internal.GrpcAttributes.securityLevel=NONE, io.grpc.Grpc.TRANSPORT_ATTR_REMOTE_ADDR=null, io.grpc.Grpc.TRANSPORT_ATTR_LOCAL_ADDR=null}
```
This issue is actually two related requests:
1. When using a domain socket with KQueue or Epoll, the security level should be `PRIVACY_AND_INTEGRITY`. I don't believe it is possible to snoop on the data going back and forth without root privileges. There doesn't appear to be a lot of information about how these values should be interpreted. For context, I am calling my gRPC Java server from the `grpc_cli` tool, which treats UDS channels as a credentialed connection.
2. The remote and local addresses should be set from the _parent_ socket for domain. Unlike regular Inet sockets, Netty doesn't set the address on the child channel for domain sockets on the server side. Netty only sets the addresses on `bind` and `connect` calls, which don't happen on the server side (the corresponding Epoll Socket channels, and Nio Socket Channels set the values more eagerly). Arguably this is a Netty bug, but it would be reasonable to work around this on the gRPC side.
One other passing thought: Connections over the loopback adapter for Inet sockets could also be reasonably treated as secure as well. gRPC C-core treats connections where both sides are loopback as special, which is nice. However, unlike domain sockets, they aren't "authenticated" IMO, which is mentioned in the docs for `SecurityLevel`.
Contributor guide
Assessment
This issue has not been assessed yet.