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

Geoff Simmons geoff at uplex.de
Mon May 15 11:05:43 CEST 2017

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

(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?)

- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

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

Version: GnuPG v2


More information about the varnish-dev mailing list