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

Harlan Stenn stenn at ntp.org
Tue Jul 14 19:31:06 UTC 2009


Dave,

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

I have a solid memory of us discussing this - it was one reason you
insisted the code be disabled by default, and why we wanted to put
suitable warnings in the documentation.

Regardless:

- It's only a potential problem for people who choose to explicitly
  enable it
- We can avoid the problem when we get the event loop code in place

And if you are still concerned about the risk we can throw a suitable
#ifdef around the actual dangerous bit (perhaps with a #else clause that
contains an msyslog() call to warn that the code was wanted but not
enabled) until we can better resolve the issue.

H
--
> 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
> >  
> >
> 
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers


More information about the hackers mailing list