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

David Mills mills at udel.edu
Tue Jul 14 19:14:57 UTC 2009


Harlan,

No, Dave Mills doesn't know that. I understood the call to 
send_via_ntp_signd() was nonblocking. If it can potentially block, it is 
a showstopperr.

Dave

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