> On Apr 5, 2017, at 5:42 PM, Jie Yu <yujie....@gmail.com> wrote: > > 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?
I can look into that. So you would consider this approach a reasonable mitigation? > > - 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
