On 02.09.2012 13:40, Simon Kelley wrote: [] > The explanation for the current state of affairs is here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508560
Oh. I tried to find why/when this subdir appeared, but failed. The changelog mentions PID in uppercase ;) I'm sorry about this, knowing that I'd have much more useful bugreport. > /var/run/dnsmasq is owned by user dnsmasq so that dnsmasq can unlink the pid > file when it shuts down, even though at that point it is running as user > "dnsmasq", not as user "root". This is a very general issue with daemons dropping privileges and their pidfiles. Each package solves it in its own way. Some forks a worker process which does setuid(), with a root-owned babysitter waiting for it to exit and clean the pidfile. Some keeps the pidfile open and truncates (not unlinking) it on exit. And some merely ignores this issue. And I think this 3rd option is the best in this case. The daemon itself does not _use_ the pidfile, it merely writes the pidfile. And tools like start-stop-daemon usually check /proc/$PID/exe or equivalent for the right executable, so, even if we'll leave the stale pidfile, no harm will be done at all. #508560 has minor severity, and I think it is just cosmetic thing. Note: having user-writable /var/run/FOO subdir, or keeping /var/run/FOO.pid open after dropping privileges are both, well, risky, since in both cases the process in question gains more privileges than actually necessary. It only needs to REMOVE (or clear) one file, but it can fill whole /var/run, or write some garbage to the pid file to trick the startup script (run as root) to execute some evil code. So I think just stopping caring (and reintroducing #508560) is the best thing to do. And by moving the pidfile back to /var/run/ we're back to the documented place and to no need for extra args. (But such "moving back", if choosen, should be done carefully -- the initscript may need to continue providing /var/run/dnsmasq/ dir, now without chowning it, since old config may need it. Sigh.) Answering to the other your email: O_EXCL exist, yes, but we still have more privs (with writable subdir in /var/run/) than necessary. Not as dangerous as current way, but still a bit too many. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
