> 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 _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev