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