On Sat, 20 Aug 2011, Russell Coker wrote: > On Sat, 20 Aug 2011, Adam Borowski <kilob...@angband.pl> wrote: > > > 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 > > Ignorance means not knowing. Sure there are probably some bug reports about > man pages due, but it's still something you or I could have found out.
... > > 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. > > Yes, SunRPC and anything that opens a port for callback. Firewall port blocking can also cause such problems (denial of service). While it is a different problem, it has the same roots as SunRPC binding to undesired sockets: applications that use random sockets do not know whether they're going to get a socket they're supposed to use. Intelligent use of conntrack can help on single hosts (reducing the problem to incoming callback connections), but most sites have border policies that forbid any traffic to flow for some ports. It causes minor issues for DNS traffic (timeouts on a small fraction of the queries), for example. > So it seems that some sort of blacklist is the only way to go. Yes. And we can easily maintain a current one for Debian-packaged software, although the initial build of such a blacklist will take some work. > The idea of a .d directory for blacklist files such that every package > installation that is likely to use some ports will automatically have a > reservation is a good one. Of course there's still the corner case of trying > to install CUPS (or some other daemon) after a long-running RPC service has > grabbed the port. That's not such a big problem, as it will be noticed immediately and causes no surprise downtime of a service. > Maybe we should default to having ports such as 631, 993, 995, 873, 587, 636, > 546, and 547 reserved at all times. From a quick scan of /etc/services they > seem to be the most likely ports to be used in the 500-1024 range. Looks good, and we can take extra ports as bug reports. A mail to d-d-a and a short article to planet.d.o and LWN may help to raise awareness of such issues: although this _is_ a longstanding and _well known_ issue, the ways to avoid the worst problems it can cause are _not_ well known. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
