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

[Geoff Simmons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/25/2017 04:42 PM, Dridi Boukelmoune wrote:
> 
>> ## Access permissions on the listen address For the ``-a``
>> address, I suggest an optional means of specifying who can access
>> the UDS: ``` varnishd -a unix:/path/to/uds:uid=foo,gid=bar ```
> 
>> If no access restrictions were requested, then don't manipulate 
>> ownership, let bind create the UDS, and set its permissions to
>> 0666.
> 
> Wouldn't it be based on umask instead?

This is something that I unfortunately never responded to, but I want
to get back to it as a comment on the current draft of VIP17, since
the VIP now has this as a kind of example:

varnishd -a /path/to/http.sock,proto=<proto>,uid=varnish,mode=0600

First of all (a lesser matter): OK, we can go with commas as a
separator, with the consequence that UDS paths may not have a comma.
There is a precedent for that with -sfile.

The more important matter is the mode. *If* we want to do this -- set
access restrictions on a listen UDS for UID and/or GID --, then if I'm
understanding the various platform quirks correctly, we can't have a
mode option. Because if you want to restrict access to a user and/or
group, then the management process will have to set permissions a
certain way, and the user cannot have any options.

For connect(2), BSD-derived systems don't care about permissions on
the UDS path at all. That is, the permissions can look as if you
couldn't access it, if it were a regular file, but nevertheless
connect will succeed. However, you can restrict access by restricting
the directory to which the UDS belongs. (This is what I read in the
docs, haven't tried it myself.)

With Linux, however, the process that calls connect(2) must have both
read and write permissions on the path.

I believe that covers all the possibilities for the platforms that
Varnish supports.

So it seems to me that this would have to happen (remember that bind
creates the path):

- - If uid and/or gid are specified in -a
  - bind and set read access on the containing directory for uid
    and/or gid, no access for other
  - set read/write access on the path for uid and/or gid, no access
    for other
- - otherwise (the UDS should be accessible to everyone)
  - bind and set read/write access for everyone on the path

That would mean that users don't have any options for setting the
mode, the management process has to control that. Setting mode in -a,
in the best case, would get it just right, but would most likely screw
it up.

If you don't do anything, then yes, the permissions on the path
created by bind depend on umask. But if we want to implement access
restrictions, then I believe we'd have to do something like this.

Another possibility would leave the "otherwise" case to whatever
results from umask. Or that we don't implement this feature at all, at
least not in the next release. But in either case, I'm not sure if
"leave it to the umask" is a good idea, it might result in other
processes being unable to connect, forcing users to set a umask before
starting Varnish. They would have to know to do that, for one thing,
and they might have to set a wide-open umask that we wouldn't want
otherwise.

(Incidentally, we'll have to decide what Varnish does if the UDS path
already exists before the bind, which causes bind to throw EADDRINUSE.
unlink and then bind, or throw the error, requiring users to make sure
it doesn't exist before starting Varnish?)


Best,
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZGW9nAAoJEOUwvh9pJNURaxQQAIlpTRr7/oxcytIQRxXd3WfS
q/L3OvhuZ2cm0RhylAVscKvse951rFL0yHx1oUJdzxnkCQ7ZRvGwjixBvD8mzgaa
R2IWWfQwO/cT4FKB4sYLJOxJMUS1zeWa8Kh9WDa/UOijH67RWsoasNfewvLLjWfX
qJjzIoc7YN5WzAXf1j4BJqvsbH5Q8xN38TMMxqVQ6XhyL+QieSxGK3y2hEYTHz27
jgWGxR1iTOknawYYQPXRyRZqnzkgMLjdIQuNTZWZtUKoLqu1x+UuJ/Rs9Sn31YrN
Uc6Q00Dz6dYf3WyeoKc2SGZmCmVYcYZf7E0y+KLbJQSBQK0uBafCvU8teXAotLDL
PqitZjvgh2EkFn8dVzKubbg0zQesWXMU5I8BHf5zau2NN4nKD+PPs8Fb1sTsiAL2
JZ2MyJfvr47NMUoto4jcgduNupAdqglPuzzir3hmyl45pIgD2PMTprwmcyOYq1j4
05ystoyHWan0KXHO8aWBKF38dIhh1DJjYnF6b1ZU83RlXnhfQEeZBufoN9nl+BzO
CojUxCnzIoHF08XJrQp+y8cGBJ6u4bfcfeqdY5CjeTWRhKiJrOZh7/47d2EpOZ7Y
ctZ6pQM3/EwdBlMLCb2q6hs2J2agyQ76izDAs+T8pOy08XN1ppc2Poh6Y6zxI9TH
1jNDph4vSKCuP6JlZwpG
=b2M/
-----END PGP SIGNATURE-----