One comment here is that: We plan to support libprocess communication using domain socket. In other words, we plan to make UPID a socket addr. Can we make sure this approach also works for the case where UPID is a unix address in the future? For instance, what will `socket->peer();` returns for domain socket?
- Jie On Wed, Apr 5, 2017 at 3:27 PM, James Peach <jor...@gmail.com> wrote: > Hi all, > > Currently, libprocess messages contain a UPID, which is send by the peer > in the HTTP message header. There's no validation of this, so generally > messages are trusted to be from the UPID they claim to be. > > As an RFC, I've pushed https://reviews.apache.org/r/58224/. This patch > constrains the UPID to not change for the lifetime of the socket, and also > enforces that the the IP address portion of the UPID matches the peer > socket address. This makes UPIDs more reliable, but the latter check would > break existing configurations. I'd appreciate any feedback on whether this > is worth pursuing at the lib process level and whether people feel that > this specific mitigation is worthwhile. > > thanks, > James
