[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup



On Sat, 20 Aug 2011, Adam Borowski <kilobyte@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.

apt-get source libc6

> 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.

> 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.

The problem with this theory is the fact that the problem that was reported 
with CUPS only occurred after bindresvport() had used every port from 1023 
down to 631.  A casual scan of /etc/services reveals that there are no long 
contiguous ranges available without reserved ports.  If you start at the top 
the common ports pop3s and imaps could be reached quite quickly.

So it seems that some sort of blacklist is the only way to go.

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.

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.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/


Reply to: