On Sat, Aug 20, 2011 at 12:02:12AM +1000, Russell Coker wrote: > On Fri, 19 Aug 2011, Adam Borowski <kilob...@angband.pl> wrote: > > Not to mention bindresvport() removes the freedom of the sysadmin to bind > > services to whatever ports she wishes. Or, say, run multiple instances of > > a service. > > If you make your program use bindresvport() then it means that you don't care > what the port number is as long as it's in the reserved range.
Except that it should not get into ports used by something else. > It seems to me that the only problem is if you run multiple instances of a > daemon on different ports and don't use /etc/bindresvport.blacklist, SE > Linux, > or some other method of telling bindresvport() to leave your port alone. > That > wouldn't be an issue of sysadmin freedom but sysadmin ignorance (and I am one > of the people who was ignorant of bindresvport.blacklist). You can't blame "sysadmin ignorance". I've just grepped through every single man page in Debian (ok, amd64 main), and there is not a single reference to /etc/bindresvport.blacklist. In fact, even bindresvport() is referenced only from its own manpage and from portreserve which is another hack to work around this bug. portreserve is neither recommended/suggested, nor has any data that would allow it to work. No other daemon I know has this problem. If I install daemon foo, I can expect it to not touch any ports it hasn't been configured to use. It's just portmap/SunRPC that uses random scatter-shot that can trample on something else. So what about this: let's reserve a number of ports for portmap's exclusive usage[1]. There's like 900 unused assignments, so there's plenty of space than could be parcelled off. SunRPC has long since degenerated from something with a general purpose to a peculiarity of NFS, so not many ports are needed. Only under a pathological configuration one could exceed any reasonable static limit, and in that case bindresvport() would revert to the blacklist+scattershot. [1]. Unless the sysadmin knowingly takes them for some other purpose; no different from, say, having sshd listen on port 443. -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110819175346.ga26...@angband.pl
