[ntp:hackers] unprivileged ntpd prototype

Brian Utterback brian.utterback at sun.com
Mon Nov 2 19:26:18 UTC 2009



Dave Hart wrote:

> I understand your thinking here regarding changing the local port, but
> why do you think adding a single source with a non-default remote port
> should trigger using the synthetic clock?  I have dreamed up one
> scenario where you might choose to run with the synthetic OS clock on
> the standard port, with an alternate-port ntpd controlling the OS
> time.

Good point. So, you would still need a flag, but I still think that 
using a non-standard port should imply that flag.

> 
>> I
>> think we are opening a major can of worms by adding a fully functional
>> method of using NTP on alternate ports. Right off the top of my head I can
>> guarantee you that there will be people that end up accidentally running
>> more than one copy of ntpd using different ports on the same machine, all
>> trying to discipline the clock.
> 
> "it hurts when I do this..."

Except it is instead "it hurts when someone else does this..."  Unless 
there is a way to detect that there are two ntpd processes updating 
the clock, we should prevent the non-standard one from doing so.

You know, all of this makes a mockery of most of the reasons Danny 
gave for listening on all interfaces.
> 
>> And there will be entire NTP networks
>> deployed using ports other than 123. Now, that may not be a bad thing, but I
>> know that this idea has been rejected in the past, and it seems like a bad
>> idea to let it slip through a back door.
> 
> Back door?  I'm a bit lost by that sentiment.  I'm also failing to
> understand why it is our job to prevent our users from choosing to
> operate a network on ntpds on nonstandard ports.

Maybe it isn't. But the idea has been proposed before and has always 
been rejected. If it was a bad idea before, then we should not 
implement it as a side effect of a "testing" feature. If it is no 
longer felt to be a bad idea, then we should be upfront about it.

> 
>> Also, I think we need an explanation of the synth_clock model. What does it
>> really tell you in use? Using the system clock at least tells you something
>> about the clock on the system, although you would need to disable attempts
>> to correct the frequency. But I am not sure I can say anything about
>> anything with the synth_clock model.
> 
> I'm not sure the synthetic clock will be useful for anything but
> testing and comparison of more than one ntpd on the same host.  That
> is my motivation -- machines that are already running ntpd can run
> another configuration of ntpd alongside, or several, happily twiddling
> a synthetic clock.

Ok, but without an explanation of the synth clock model, it will only 
be useful for testing and comparison of more than one ntpd on the same 
host by you, no one else.

> 
>> There are a number of methods for IPC on Unix, but I am not sure it is a
>> good idea to use any of them. Adding another I/O method seems like overkill
>> to me, or if not overkill, then ill-advised. Perhaps this could be added to
>> the either the request or control protocols?
> 
> I'm talking about a way of informing that a step has occurred. I am
> looking for an IPC semaphore of some sort that can be waited on
> efficiently by multiple ntpds.  Tacking it onto the existing protocol
> would require some method of discovering which local ports are used by
> all running ntpds, and iterating over them sending the notification of
> the step to each.  That seems like overkill to me compared to using a
> means where a single notification is received by all interested
> parties in one operation, which I believe a named event will
> accomplish on Windows.

I understood what you wanted. Perhaps a shared memory mechanism would 
be best. We already support shared memory, and it would be easy enough 
to have a ring buffer of clock change events maintained by the "real" 
ntpd to which other ntpd's could subscribe.

-- 
blu

It's bad civic hygiene to build technologies that could someday be
used to facilitate a police state. - Bruce Schneier
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list