RFC for VIP17: unix domain sockets for listen and backend addresses

[Dridi Boukelmoune]

> OK, that should be documented though (there is other software that
> works with UDSen that does in fact unlink before bind).

There should be a limit to hand-holding. I have bitter memories of
tracking down processes holding unlinked files around and leaving a
partition with no space. The upside was that it introduced me to
lsof(1) at the time.

I would invoke POLA, at least it would feel surprising to me, not
being sure what service I'm connecting to when I pick a path.

>> The question here is more whether we need something like
>> beresp.backend.path in addition to the ip field. Same question for
>> peer credentials, they probably don't make sense for backends (and
>> that would keep the new std functions limited to the listen
>> addresses type).
>
> For the long-winded reasons stated above, I disagree that it doesn't
> make sense. %^) Especially since connect(2) doesn't create the path as
> bind(2) does, getting peer credentials on a backend address is about
> the only thing that could be expressed in VCL about who the peer is
> intended to be, that goes beyond assuming that the admin got it right.

Well, I was cautious enough to say probably. I'm basing my reasoning
on the fact that Varnish tends to trust the backend. It was recently-ish
reconfirmed [1] by phk.

>> Is the question of naming from the original draft still relevant?
>
> That was about VTCP_name, _hisname and _myname, so one way or another
> we'll have to decide what happens with those. We could drop them and
> have them do what they do some other way, and introduce something else
> again where they're currently called, when it's a UDS. git grep on
> those function names currently gets over 30 hits, so that would be a
> bit of a chore. The suggestion in the original draft was to avoid the
> pain -- leave them as they are, and have them create names for UDSen
> in way that doesn't change their interfaces.

I will confess I haven't researched this part thoroughly, that's why I
left it as an open question and linked directly to your original draft.

Dridi

[1] https://github.com/varnishcache/varnish-cache/issues/2197#issuecomment-275055034