What happens on large servers running sendmail when you kill and
restart the listening daemon?  If other children are still sucking mail
through port 25 when you restart the listening process, won't it fail to
bind to the port with the patch you've submitted?
-Brian
On Mar 10,  9:16am, Luke Mewburn wrote:
} Subject: Re: tightening control on socket bind()ing
} Guenther Grau writes:
} > I must admit that I don't like solution. What if two people
} > on the same machine want to listen to the same mbone video
} > broadcasting? Only the first will succeed? Maybe at least in case
} > of multi-cast sockets this restriction should not be imposed.
} 
} If you look closely at the patch you'll see that they're not affected.
} 
} > IMHO, for a clean solution, we need yet another attribute to
} > indicate if the above restriction should apply. How about
} > SO_REUSE{ADDR,PORT}_INSECURE? Programs which want to allow
} > the insecure behaviour can do so, and the existing daemons
} > will work fine. I'd prefer SO_REUSE{ADDR,PORT}_SECURE, because
} > this would preserve existing behaviour for other applications.
} > That way we'd have to change the daemons, but hey, they are
} > our code, and 3rd party sw is not.
} 
} The SO_NOREUSE concept I first toyed with was similar to this.
} However, that required changing *every* daemon, both in-tree and
} third-party.  The type of program that gets affected by this (e.g,
} web servers) often run on ports > 1024; do you want to have a
} NetBSD specific hack in the source to every freely available web
} server?
} 
} FreeBSD (which has a larger installed base than us) and OpenBSD both
} have this funcionality; so I'm sure this issue would have come up
} for them if it really was going to affect people.
>-- End of excerpt from Luke Mewburn