The following reply was made to PR bin/35479; it has been noted by GNATS.

From: Christian Biere <christianbiere@gmx.de>
To: netbsd-bugs@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/35479: /usr/sbin/timedc fails
Date: Fri, 26 Jan 2007 20:18:19 +0100

 Woodchuck wrote:
 > > I don't see a good and clean way to work around this in NetBSD. One option would
 > > be a command-line parameter to use an unprivileged port. This would still fail
 > > in a mixed environment. Another is to use two sockets and send everything twice.
  
 > Why?  NetBSD's inetd doesn't require a privileged source port.
 > The question is why NetBSD's timedc uses one.  It looks like
 > a vestige of an earlier day, unless I am missing something.
  
 > It can't be "trust"; timedc is setuid.  Unprivileged source ports
 > are serviced happily by netbsd's inetd time/udp service:
 
 Yes, you're right. I was confused. NetBSD's timedc could use an unprivileged
 port and this should not cause any problem. For a moment, I assumed it would
 only accept requests from privileged ports but as cleared before, it does not
 discriminate against any ports at all.
  
 > On the other hand, would using an unprivileged port in timedc.c
 > break interoperability with anything?  It would seem to increase
 > interoperability.
  
 > In a world of a half-billion Windoze-running "roots", and
 > another 200 million hand-cranked Ubuntu laptops about to be
 > heli-dropped on the third world, what does the use of a privileged
 > port get you?  Are there NetBSD daemons, running out of inetd, that
 > trust service requests because they come from a privileged port?
 
 Yes, services like rsh/rlogin and possibly others work that way. Of
 course, Windows machines are usually excluded from such an infracstructure
 and it requires that you have full control over your LAN (e.g., allowing
 only registered MACs etc.).
 
 -- 
 Christian