Sebastian Benoit <[email protected]> wrote: > Florian Obser([email protected]) on 2018.10.30 18:32:15 +0100: > > On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote: > > > Remi Locherer <[email protected]> wrote: > > > > > > > On Tue, Oct 30, 2018 at 03:20:35PM +0000, Ricardo Mestre wrote: > > > > > Hi, > > > > > > > > > > After all files are opened ripd(8) can have the fs access disabled > > > > > just before > > > > > each process main loop. Its 2 childs already run under chroot, but > > > > > since they > > > > > are still not pledged at least they have no way to read/write/create > > > > > files within > > > > > the chroot. No loads or reloads of the config file happen through any > > > > > signal, > > > > > nor can we do it via ripctl(8). > > > > > > > > > > I was able to run a simple daemon with the example file. Comments? OK? > > > > > > > > control_cleanup() unlinks the control socket on exit. I think you should > > > > either unveil(conf->csock, "c") or remove control_cleanup(). > > > > > > I don't understand this latter comment, let me ask. > > > > > > You think it is smart to leave these sockets lying around? > > > > > > > Back in the summer the consensus was that it is fine to leave the > > sockets lying around. Furthermore the consensus was that it is worth > > to do so if we can drop the cpath pledge in daemons. (IIRC at least benno, > > claudio, deraadt, florian and mestre where in the loop.) > > > > mestre went on a rampage and removed control_cleanup and cpath pledge > > in a bunch of daemons. I think he stopped when he couldn't find any > > more daemons where the parent process was pledged. > > > > This was before the > > unveil("/", "r"); > > unveil(control_socket, "rwc"); > > pattern was discovered which is also very powerful. > > > > > I suspect there are a few oddball programs where it makes senes, but as > > > a general rule I think it is a bad idea; as stated in other threads it > > > means control programs and restart sequences have a bunch more oddball > > > behaviours which will be inconsistant. > > > > I want consistency, if we go with the unveil pattern, fine, then we > > should restore the control_cleanup code in a bunch of daemons. > > > > However: > > - the control program behaviour change had been discussed in the > > summer and the only difference discovered then was "file not found" vs. > > "connection refused". > > - benno's comment about only one instance of ospfd running is not > > effected by leaving the socket behind, it checks if the socket has a > > listener. a dead socket is no problem. > > - daemons/routers might crash and leave a socket behind anyway. they > > must be able to deal with this and I'm pretty sure they all do. I just > > checked ospfd, bgpd and rad. > > i agree with that. In the summer i first thought it would be better to clean > up, but the discussion back then convinced me otherwise, and florian summed > it up nicely.
Fine, but let's try to make them consistant?
