Florian Obser(flor...@openbsd.org) on 2018.10.30 18:32:15 +0100:
> On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:
> > Remi Locherer <remi.loche...@relo.ch> 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.
