From phk at phk.freebsd.dk Tue Feb 13 13:33:11 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Feb 2018 13:33:11 +0000 Subject: UDS decisions Message-ID: <13472.1518528791@critter.freebsd.dk> As you all know I've been agonizing about Unix Domain Sockets support, but I've, finally, made up my mind, and came down on the side of keeping them special, rather than generalize. I'm going to explain the thinking in this email, for posterity and so that you can squarely and fairly pin the blame on me at some later date. Tl;DR: just read the headings. Objections ? Poul-Henning 1. We will use bogo-IP numbers for client UDS connections ========================================================= VCL variables {local|remote|client|server}.ip will return VCL_IP(0.0.0.0:0) on UDS sessions. If PROXY protocol is used, it will, as now, fill {client|server}.ip Reasoning: ---------- UDS is a hack, and is used as a hack for hackish, but valid reasons. That does not warrant a very expensive generalization of everything Varnish knows about protocol endpoints and identities of other parties. This in particular because nobody cares one iota about the identity at the other end of UDS connections and moreso because UDS does not uniqely identify each UDS connection. By using a bogo-IP number, we give people the ability to filter UDS connections in ACLs. We also avoid large-scale boiler-plate code changes that almost all amount to "if (X->sa == NULL) ... else ..." where there is no sane alternative but to invent a bogo-text for the NULL case. 0.0.0.0/8 is registered at IANA as "This host on this network" which is where INADDR_ANY comes from, and will (these days) always be changed to something different on real TCP/IP connections, so there is no ambiguity. 2. We will not log the UDS path anywhere ======================================== Reasoning: ---------- UDS paths are typically longish, exact copies of the -a argument and would thus be the same for all sessions on the same acceptor socket, thus conveying no information. This saves both VSL bandwidth and CPU time. VSL::SessOpen already contains the socket name, defaulting to "a%d", in field three, and if you need to distinguish between UDS connections, you can simply name that -a argument. If varnishncsa cannot log field 3 of SessOpen if so asked, somebody should add that functionality. 3. We will not adapt struct suckaddr to UDS addresses ===================================================== Reasoning: ---------- The reason we have struct suckaddr is primarily because TCP connections keep copies of the connection endpoints in struct sess and sockaddr_storage was a waste of space for that. Given that we dont need to log the UDS path, we don't need to store it in struct sess, so we don't need them in struct suckaddr either. The only actual place we will need sockaddr_un is in the acceptor and we only need one per UDS acceptor socket. 4. backend.ip also gets bogo-IP =============================== Backend.ip will return VCL_IP(0.0.0.0:0) unless the director has a real IP endpoint to report. Reasoning: ---------- Directors were not supposed to be limited to IP connections and backend.ip was, in hindsight, a mistake, but it is useful and popular in VCL code. Avoiding NULL checks (like under point 1) makes sense. 5. We will have a global, constant bogo-ip variable for this ============================================================ extern const struct suckaddr bogo_ip; Reasoning: ---------- For coding convenience. But do *NOT* simply compare the pointer, use VSA_Compare(). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From slink at schokola.de Tue Feb 13 14:47:22 2018 From: slink at schokola.de (Nils Goroll) Date: Tue, 13 Feb 2018 15:47:22 +0100 Subject: UDS decisions In-Reply-To: <13472.1518528791@critter.freebsd.dk> References: <13472.1518528791@critter.freebsd.dk> Message-ID: <1e149bf9-4347-d924-8942-803b8e4ddc57@schokola.de> WFM, but one thing: > 1. We will use bogo-IP numbers for client UDS connections As long as we get VCL access to the accept socket name, we should not need the uds socket path. But we should have a way to differentiate between /untrusted/external.socket and /highly/secure/internal.socket Nils P.S. FTR I can't quite follow the "UDS is hackisch" argument, but that discussion would not get us anywhere. Nils From dridi at varni.sh Tue Feb 13 14:54:51 2018 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 13 Feb 2018 15:54:51 +0100 Subject: UDS decisions In-Reply-To: <1e149bf9-4347-d924-8942-803b8e4ddc57@schokola.de> References: <13472.1518528791@critter.freebsd.dk> <1e149bf9-4347-d924-8942-803b8e4ddc57@schokola.de> Message-ID: On Tue, Feb 13, 2018 at 3:47 PM, Nils Goroll wrote: > WFM, but one thing: > >> 1. We will use bogo-IP numbers for client UDS connections > > As long as we get VCL access to the accept socket name, we should not need the > uds socket path. But we should have a way to differentiate between > /untrusted/external.socket and /highly/secure/internal.socket That would be "named listen addresses" described in the same VIP as UDS, and currently half-implemented in trunk (names exist, but aren't usable in VCL). While at it, WFM too. Dridi From phk at phk.freebsd.dk Wed Feb 14 08:27:26 2018 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 Feb 2018 08:27:26 +0000 Subject: UDS decisions In-Reply-To: <1e149bf9-4347-d924-8942-803b8e4ddc57@schokola.de> References: <13472.1518528791@critter.freebsd.dk> <1e149bf9-4347-d924-8942-803b8e4ddc57@schokola.de> Message-ID: <30831.1518596846@critter.freebsd.dk> -------- In message <1e149bf9-4347-d924-8942-803b8e4ddc57 at schokola.de>, Nils Goroll writ es: >WFM, but one thing: > >> 1. We will use bogo-IP numbers for client UDS connections > >As long as we get VCL access to the accept socket name, we should not need the >uds socket path. But we should have a way to differentiate between >/untrusted/external.socket and /highly/secure/internal.socket Something like 'local.endpoint' and/or 'local.acceptor' returning the address and name of the acceptor socket respectively. >P.S. FTR I can't quite follow the "UDS is hackisch" argument, but that >discussion would not get us anywhere. UDS wa a hack to absorb named pipes into this newfangled "network" part of the kernel. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.