[ntp:hackers] Samba's MS-NTP implementation

Danny Mayer mayer at ntp.org
Mon Jul 13 11:54:48 UTC 2009

Harlan Stenn wrote:
>> I have been reviewing the code that the Samba team introduced into the
>> NTP dev code base and I am seeing a lot of problems that disturb me
>> about this contribution. So let me enumerate the problems with the
>> implementation:
>> 1) The code uses a TCP socket to call another server. This is even
>> though NTP only uses UDP
> So what?  This is the code the Samba team says makes for the easiest
> integration with samba.
> That is the entire point of this whack of code.

So what you are saying is that this is for Samba only and that is a very
restricted list of servers.

>> 2) The code only seems to try to contact a Samba server but it should
>> equally be able to connect to an Active Directory Domain Controller or a
>> Kerberos server.
> Why do you say this?  The samba folks know what they need, and sent us
> code to do what they need.
> What problem are you trying to solve?

So only Samba can use this.

>> 3) The code blocks on the connect, the send (write) and the recv (read)
>> calls all of which violate the basic requirements of NTP.
> Yes, Dave Mills and I both know this and discussed this.
> Until we get event-loop code into ntp, the samba interaction *can*
> block.

The event-loop is not a cure-all and will take a great deal of time and
effort to get into the NTP source and working. Don't put too much
expectation on it.

> Therefore we default the samba code to "off" and we warn people (at
> least we *should* be warning them) about the problems they *may* have if
> they use this code.
> And as I understand it, the new MSSNTP 'restrict' code can limit the
> networks that ntpd will even talk to about this.
>> I am unsure of the affect of using this on a Windows system.
> Why would you want to run Samba on a Windows box?

"Why wouldn't I want to run NTP on an active directory domain
controller" is the correct question. We are ending up with a solution
that only works for Samba.

>> 4) The code uses AF_UNIX instead of AF_INET or AF_INET6 as appropriate
> What problem are yo trying to solve?  This stuff is all on the local
> machine.  What is the problem with using an AF_UNIX socket to talk
> between ntpd and samba running on a Unix box?

If you only want to run it on a Unix box running Samba, that's fine,
it's just very limiting.

>> 5) The time for another server to respond is indeterminate and cannot be
>> relied upon.
> Yes, so what?  This is also going on (near as I can recall) in between
> T2 and T3, so the amount of time it takes doesn't really matter.

Actually it's worse than that since you are now holding up the
processing of other incoming packets and delaying timestamping them.

>> 6) The requirement that it waits for another server makes it easy to
>> mount a DOS attack on such an NTP server.
> Yes, and since this service should only be set up to support local
> users, there is less risk.  And we document this.

The documentation that I have seen so far has not said a word about this.

>> 7) The reliance on another server increases the likelihood that the
>> jitter and delay will increase enormously in unexpected and unreliable
>> ways and that is something that NTP cannot afford.
> Says who?  And if indeed this interaction is between T2 and T3, where is
> this problem you speak of?  And if this really does turn out to be ab ig
> deal, we'll hear about it, see if we can fix it, and either way folks
> can decide to use it or not.

The delay in processing other incoming packets affects the timestamps.
That's why we insist on non-blocking for the DNS lookups.

>> 8) There maybe some issues over the copyright of the protocol which is
>> covered under Microsoft's Open Specifications copyright but I am not a
>> lawyer and cannot say if there are any legal issues involved with this
>> code.
> I'm not a laywer either so neither can I.  We got the code in good
> faith.

I'm not talking about Samba's code, I'm talking about Microsoft's
licensing of the protocol.

>> This is so at variance with the NTP design requirements that I am
>> recommending that we completely remove the Samba contribution from the
>> 4.2.5 code at this time. If at some point in the future this can be done
>> without involving a third system then it can be reconsidered. Even if
>> this is released we should explicitly be turning off this capability and
>> require that anyone who wants to use it turn it on.
> It is *already* off by default.
> It *already* requires specific action to turn it on.  
> And I hear your recommendation.  We (me, Dave Mills, a bunch of other
> folks) have been discussing this proposal for quite a long time now
> (since May 2008, and before that, Novermber of 2006), and I suspect you
> knew about this.

I don't recall a discussion of the blocking issue but maybe I missed it.

> Even if it wasn't so late in the game, the dangers of enabling this
> capability are well understood and documented, and there are significant
> complications if we do *not* have this capability.

Where is it documented?

> Furthermore, I believe most of the "danger" in this capability will go
> away as soon as we have a useful event-loop in the mainline code.

Again don't expect too much of the event-loop processing and this code
would have to be decomposed to be non-blocking to be any use to the
event-loop processing.

> So far I've heard only good things about this code, and no reports of
> problems.
> That's good enough for me, given the current default behavior and the
> warnings and caveats to those who intend to use it.
> I am again reminded of my favorite between-the-lines Bible Quote:
>  Blessed are those who get what they deserve.

I'm more concerned about the Principle of Least Astonishment.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the hackers mailing list