> In article <Pine.BSF.4.03.9810181640060.20832-100000@alive.znep.com>,
> Marc Slemko <marcs@znep.com> writes:
> > marcs@lerkim:~$ nc -v -l -p 8888 &
> > [1] 6475
> > marcs@lerkim:~$ listening on [any] 8888 ...
> > nc -v -l -p 8888 -s localhost
> > retrying local 127.0.0.1:8888 : Address already in use
>
> > marcs@lerkim:~$ nc -u -v -l -p 8888 &
> > [1] 6477
> > marcs@lerkim:~$ listening on [any] 8888 ...
> > nc -u -v -l -p 8888 -s localhost
> > listening on [127.0.0.1] 8888 ...
>
>
> > If I bind a TCP socket to INADDR_ANY with SO_REUSEADDR set, then try to
> > bind to a specific address, it is denied. Trying to do the same thing
> > works with UDP.
>
> > Aside from the fact that being able to do this is a useful feature, it is
> > inconsistent between UDP and TCP.
> Being able to do this is a security hole because you can steal packets
> from other processes then. If UDP allows it is a bug IMHO.
Sorry, I already said I don't buy that argument in the bit you cut out.
I can't think of any other OS that has taken such draconian steps to avoid
this problem. There are other solutions (eg. using socket credentials to
only allow the same user or root to bind more specifically) that work just
fine without adding another gratuitous incompatibility. We will ignore
the fact that any app which relies on such things to avoid a security hole
is broken anyway, since all you have to do is crash it.
This is a basic functionality and I haven't encountered any other Unix
type OS that is mainstream and has this odd behaviour.
UDP has to allow it, at least for the same process, because many common
apps (eg. named, ntpd) do it based on the fact that in a traditional
environment you have to bind to each address specifically to know what
address to use in a reply.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/