+ BenM James, I don't have immediate context on this issue. BenM will be back next week and he should be able to give you more accurate feedback.
- Jie On Fri, Apr 7, 2017 at 8:37 AM, James Peach <jor...@gmail.com> wrote: > > > 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 > >
