PROXY and Unix domain sockets

[Geoff Simmons]

Hello all,

Again I'm writing in the hope of soliciting opinions, this time
pondering support for UDS in the PROXY protocol.

If we release a version of Varnish as "now supporting UDS", it might
seem logical to support UDS for PROXY as well. But that doesn't
necessarily follow -- if Varnish supports UDS for listen and backend
addresses, it may still reject PROXY headers that denote a UDS.

As of now, I'm thinking that would be the right way to go. But I'm a
bit concerned that there may be no good way to support PROXY with UDS
in the foreseeable future, for reasons I'll try to explain.

For one thing, the use case is evidently marginal. UDS in a PROXY
header would mean that someone is running a proxy that listens at a
UDS and forwards to Varnish, and wants to tell Varnish via PROXY about
its UDS listen address. That setup is evidently rare enough that no
one seems to have complained about Varnish rejecting such a PROXY header.

Also, PROXYv1 (the human-readable format) doesn't support UDS, The
address family is either TCPv4 or TCPv6, anything else is UNKNOWN.

So the only the possible scenario is receiving AF_UNIX via PROXYv2.
Conceivably, we could support that.

The difficulty I see is:

* We convert the addresses from the PROXY header to VSAs, which become
the session attributes for the client and server addresses in session
workspace.

* We wanted to avoid adding the storage for sockaddr_un (128 bytes
each, with about 100 bytes for the path) to session workspace.

* I can't think of any good place besides session workspace to put the
UDS addresses sent via PROXY.

When PROXYv2 sends AF_UNIX, there are two addresses, 108 bytes each,
so the protocol specifies 216 bytes. Where should the storage go?

So far in the fork, I have VSAs with a pointer to sockaddr_un, and
someone is the "owner" of the storage that it points to, responsible
for freeing it. So VSAs don't become any larger, and don't take up
more session workspace (on my machine, a VSA is 40 bytes).

For listen addresses, the owner is the management process, who has the
pointers to the sockaddr_un's in the pool of listen_socks, which is
handed off to the child via heritage.socks. The pool is valid for the
lifetime for the mgt process, so the sockaddr_un storage just dies
when mgt exits (this was already the case for the pool of listen_socks
before the introduction of UDS).

For backend addresses, the owner is struct backend, which now has
pointers to a UDS VSA and a sockaddr_un. These are freed in VBE_Delete.

In any other UDS VSA duplicated from one of those, such as the session
attributes or the TCP pool for a backend, the pointer to sockaddr_un
in the VSA is copied from the owner -- it "points back" to the space
managed by the owner. Those components don't attempt to free the pointer.

I'm pretty happy about how this has turned out, because I think it
keeps the sockaddr_un storage needs down to the minimum necessary, and
manages the storage the right way. (Still interested in feedback about
that.)

But as presently conceived, the addresses sent via PROXY are "owned"
by a session, and become invalid when the session closes.

Theoretically, PROXY could send a different address every time, but in
practice the address sent would be the same almost every time, at
least on one listen address. So we could have an external table of
sockaddr_un's created from PROXY headers, and VSAs in session
workspace would point to entries in the table.

That would mean sessions receiving a UDS via PROXY would have to
search the table, strcmp against their paths, and insert new
sockaddr_un's as necessary. Something would have to take care of
garbage collecting the table occasionally.

At any rate, my recommendation is:

* Don't support UDS via PROXYv2 for the time being, even if we support
UDS for listen and backend addresses.

* Put the question of storage for sockaddr_un's derived from PROXY on
the list of ponderables for the future.

As usual, comments are welcome.


Thanks,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20170712/6c38040c/attachment.pgp>