Anybody know how to debug things like this?
Eric S. Raymond
esr at thyrsus.com
Fri Jul 15 12:41:16 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> esr at thyrsus.com said:
> > The only safe alternative would be to force the initial DNS lookups to be
> > synchronous.
> That doesn't work for the pool case. It wants to get more servers if some of
> the ones it is using stop responding.
> > A: get configuration (that's the early thread launch)
> We could split the DNS lookups out of that. It would add a new step to your
> > E. initializing = false
> > Moving F and B is no problem, but the others worry me - especially the
> > setting of initialize, which does things I don't understand to the protocol
> > machine. My spider sense is tingling.
> The DNS lookups may take a long time, so starting them a bit later should be
> It wouldn't surprise me if we discovered problems. That's a mixed blessing.
> Finding problems is always good, but we would also have to to fix them.
> I've found 2 more quirks associated with early sandbox.
> The PID file needs to be writable by ntp. That should be easy to fix - just
> some scripting before starting ntpd. systemd doesn't have that scripting,
> but it doesn't use a pid file.
> The other is that NetBSD won't let ntp open wildcard sockets. It may be
> sockets with port# less that 1024. I don't have a solution but I haven't
> looked very hard.
I'm in favor of cleaning up and fixing some of these order
dependencies, but I'd rather get us to a safe and functioning state
first. Accordingly, splitting out seccomp() implementation to do it
early and keeping droproot late is looking better and better.
In some sense this is my error. I think it used to work as above until
I created sandbox() to hide all the ugly platform-dependent privilege
containment stuff in.
I just managed one relevant refactor. The "initializing" global is gone.
That will simplify later changes a lot.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel