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

[Dridi Boukelmoune]

> 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.

Yes, we can probably get away with no commas in file names.

Also see this comment from phk:

https://github.com/varnishcache/varnish-cache/issues/2325#issuecomment-301413244

> 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.

Well, we can always set a mode and let users refer to the UDS docs of
their platforms.

> 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

I'm not fond of fiddling with directories we don't own, for example,
what if the user picks /tmp/varnish.sock?

>   - 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.

My take on it is do nothing unless a mode was specified when the
socket is created. Simple for us, leaving the users in control.

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

If we can't bind, we should just fail the startup. Varnish shouldn't
do the sysadmin's job.

Cheers,
Dridi