Daniel Franke <dfoxfra...@gmail.com>:
> On 7/5/16, Eric S. Raymond <e...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
