On Wed, 2011-03-30 at 14:20 +0000, Jim Harrison wrote: > Interesting... > Windows also has similar functionality offered via .NET services (Net.Tcp Port Sharing http://msdn.microsoft.com/en-us/library/ms734772.aspx), but this is only available through .NET API; not directly through Winsock or AFD. I suspect the BSD implementation you discovered has similar goals in mind (expanding the TCP socket limits), but didn't go as far with the solution. > The BSD folks indicated that this is "by-design" - did they also point you toward any management API beyond making the socket "protected"?? I don't believe it is anything like the .NET functionality you mention. After reading the article, I get the impression that this is specific to HTTP and is a combination of virtual hosting and reverse proxy. (I may be wrong, I only skimmed through the document.) I can see why this [BSD] functionality might desired. If you have a server with several interfaces and/or alias addresses, you can bind a service to specific address/port for multiple interface/alias (each an independent process running as a different user and serving different content -- that's fine, we do this all the time) and have a "default" service listening on the wildcard interface which will respond where there is not specific address/port service. But unless you are designing a service to function this way, it's a very bad idea to enable this feature by default, and really, it should only be enable on the port where it is desired. Imagine if you find a Solaris system running a web server that has a remote exploit which allows for the execution of arbitrary code. If the web server happens to be listening on the wildcard interface than you can very easily insert your own web server in front of it! -- Chris O'Regan <chris@xxxxxxxxxxxxxxxxx> Senior Unix Systems Administrator, Academic IT Services Faculty of Engineering and Computer Science Concordia University, Montreal, Canada
