Requesting code review on possible fix for nopeer/pool conflict
Eric S. Raymond
esr at thyrsus.com
Tue Jul 5 15:59:32 UTC 2016
Daniel Franke <dfoxfranke at gmail.com>:
> On 7/5/16, Eric S. Raymond <esr at thyrsus.com> wrote:
> > Hal's bug report reads like this:
> > restrict nopeer kills using the pool command. (Try it.) The symptom is
> > that no slots ever show up in ntpq -p
> > The nopeer restriction is intended to prevent attackers from
> > pretending to be a peer and then screwing up the local clock. The pool
> > command is using the same peer mechanism to setup a temporary slot. We
> > should be able to bypass that part of the restrict filter. We know
> > what IP address to expect. The server slots already do it.
> I think this working as designed. 'restrict nopeer' means "Don't
> establish unauthenticated ephemeral associations with this IP
> address", which is exactly what pool does. I agree this is stupid
> design but I don't think it's a bug. One more reason I need to get my
> ACL language implemented and restrict needs to die.
> The whole receive() function you're looking at is about to get blown
> away in my ntp_proto refactor. Can you hold off on touching it until
> next week?
Yes, I can.
I think there is an argument that pool servers ought to be treated specially -
that, in fact, the pool keyword *means* that we should trust unauthenticated
peerd recommended by the pool dispatcher.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel