-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 3 Jun 2001, horape@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> > > The following program binds *:1000 to a socket, and then tries to bind
> > > 200.47.36.254:1000 to another socket, the error i gets is "Address
> > > already in use". Why?
>
> > If this wasn't prevented, it would be a security hole. If the same
> > application wants to do a wildcard bind and then a specific bind to the
> > same port, that's all fine and good, but consider if it was two different
> > applications.
>
> Why won't just allow binding to a "more specific" address if the new
> proccess wanting to do that binding is running with the same uid that
> the older one? (that's afaik how the 4.4BSD worked, I want to know why
> that was changed)
I imagine there are issues with some types of network applications like
FTP daemons that "hunt" for an open port by repeatedly trying to bind to
specific port numbers within a range. If the hunting was done with
specific IP addresses, it would be possible for a daemon hunting as root
to tromp over a wildcard-bound daemon listening on a well-known port.
This is just a guess though; there are probably other, better reasons and
my guess may not even be accurate. ;-)
I do remember this question came up on one of the IPv6 lists, possibly
USAGI, in regard to IPv6/IPv4 binds. And I presume this is the reason why
you're asking on netdev... -Nathan
- --
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@xxxxxxxxxx | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/
iD8DBQE7GesxTviDkW8mhycRAmHUAKCh4S8ZKjnGmJgXGIPyiSVMsx614gCgg+xz
1Wr7D5U6hGHZaXeEvw6vYvk=
=y8WC
-----END PGP SIGNATURE-----
|