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

Harlan Stenn stenn at ntp.org
Mon Jul 13 01:46:00 UTC 2009


> 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.

> 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?

> 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.

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?

> 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?

> 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.

> 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.

> 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.

> 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.

> 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.

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.

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.

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.

H


More information about the hackers mailing list