Re: dante sockd - bug report & patch - problem in sockd_socket.c use of glibc's sunrpc bindrecvport()
Roland McGrath wrote,
> It's true that current in BSD systems bindresvport simply calls bind with
> the given sockaddr unless sin_port is zero. But GNU libc has never worked
> this way (I'm not sure the original BSD version of bindresvport did
> either). It's not an option to change what GNU libc does now, because
> there are applications out there that do not initialize sin_port at all (so
> it might have a random value) and expect bindresvport to ignore the value
> and always pick a port. It's unfortunate that the incompatibility has
> arisen between BSD and GNU, but it has. It is easy enough to make your
> programs portable by always calling bindresvport only with sin_port = 0
> and just calling bind directly instead if you have already chosen a port.
Well, bindresvport(3) is also supposed to retry if it fails, thus
the reason for calling it (if you want a privileged port, preferably
port X, but not necessarily, it might be (and on some systems is),
much faster and easier to call bindresvport(3) rather than to cycle
through all the privileged ports yourself, or call bind(2) first,
and if that fails, call bindresvport(3) with a zero port argument.
If the semantics of calling bindresvport() with a non-privileged
portnumber was clear, you could have assumed the port was "set" if
it was privileged (and if it wasn't, there would be no harm in
assuming it anyway in this case), and not set if unprivileged, but
sadly that seems to vary, at least between Solaris and BSD --- BSD
will bind a non-privileged port if so requested in bindresvport(),
whereas Solaris 5.8 seems to ignore the portnumber in this case and
binds a privileged port instead.
--
_ //
\X/ -- Michael Shuldman
Received on Thu Apr 10 09:48:22 2003
This archive was generated by hypermail 2.1.8
: Wed Aug 23 2006 - 13:48:38 EDT
|