> 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 _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
