Bug 187840 - portmap picks random ports -> breaks other services
Summary: portmap picks random ports -> breaks other services
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: portmap
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
: 227411 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-03 20:46 UTC by Damian Menscher
Modified: 2011-12-08 15:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-08 15:40:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Damian Menscher 2006-04-03 20:46:35 UTC
Description of problem:
All the NIS services pick a random port when starting, which can break other
programs that start later.  I most recently saw this with ypbind starting on
port 783, which broke spamassassin.  I've previously seen this with a YP service
breaking cups (all the cups clients tried reconnecting several times/second,
which led to an iptables connection tracking DDoS against my server).  That had
apparently been fixed in FC and RHEL3 by moving S90cups to S55cups, so I'm
guessing a similar fix is in order for spamassassin.  But I'm filing this bug
against portmap since it's the YP services that are causing all the problems in
the first place, and a cleaner fix might be to implement a "blacklist" of
disallowed ports.  (Some day, dependencies might require yp/nis to start before
something else, and the port randomization will bite you.)

Note that similar bugs have been reported against RH8 in bug 85149 and against
FC4 in bug 168996.  I'm adding this bug against RHEL4 in hopes that maybe it'll
get noticed/fixed sometime soon.

Version-Release number of selected component (if applicable):
portmap-4.0-63

Comment 1 Steve Dickson 2006-07-18 15:22:41 UTC
I believe most NIS process have a '-p' flag that will define the port
they uses. Unfortunately I believe this is the only method avaiable 
at the moment.. 

Comment 3 Damian Menscher 2006-12-21 16:30:42 UTC
Closing bug reports that have been causing machines to misbehave for years is
not acceptable.  Please don't try that again.

I previously suggested two solutions to this bug.  While the first solution
(reordering services) sounds simpler (and seems to be the approach RH has
taken), it does have the problem that it's conceivable that dependencies will
cause problems.  Blacklisting all ports listed in /etc/services is likely the
best solution -- I once checked and discovered that it's actually a fairly
sparse file.  So that solution should work quite well.  I even tried figuring
out how to code a patch for that, but haven't had time.  If RH is unwilling to
commit resources to this, then reporting the bug (and suggested fix) upstream
would be advisable.

Comment 4 klaus thorn 2007-03-02 00:06:36 UTC
This problem bit me with Fedora Core 5.
portmap used port 631 for ypserv.

Cups failed to start, samba failed due to missing cups and stopped the the whole
boot propcess. Thus preventing other services from starting and reaching their
post-boot state etc.. That should make clear how serious the consequences are.

Another suggestion: do not take ports below 10000. Not waterproff, but it's an
improvement which helps in many cases. This improvement would not depend on
/etc/services or the fragile S?? init number allocation, preventing admins from
digging their own graves if they reorder the init scripts.

rpm -iq portmap says:
Version: 4.0, Vendor: Red Hat, Inc., Release: 65.2.2

Comment 5 Steve Dickson 2007-04-20 13:25:28 UTC
*** Bug 227411 has been marked as a duplicate of this bug. ***

Comment 6 Ronald Cole 2007-05-17 23:24:23 UTC
I just hit this today after installing the RHEL4 spamassassin errata!

Upon a reboot, portmap assigned port 783 to rpc.statd and so spamd refused to
start.  So guess where I assumed the problem was?  That's right... the errata
update!  While I was forced to dig into this to effect a resolution, mail was
not being processed as this server was the mailhub!  Does Red Hat really think
that pissing off CEOs will endear them to the idea of the CIO throwing more
money at Red Hat Network subscriptions if such activity doesn't result in the
problem getting fixed?

If I were to fix this, I would probably make portmap avoid any port assigned to
services listed in /etc/services; but that wouldn't work here because
spamassassin's use of port 783 isn't in /etc/services either!!

Comment 7 Damian Menscher 2009-02-06 16:56:37 UTC
Since it's clear that redhat has no intention of fixing this bug, I'll document the workaround for everyone else:

echo "YPSERV_ARGS=--port 892" >> /etc/sysconfig/network
echo "YPPASSWDD_ARGS=--port 723" >> /etc/sysconfig/yppasswdd
echo "RPCMOUNTDOPTS=--port 1021" >> /etc/sysconfig/network
echo "RPCRQUOTADOPTS=--port 969" >> /etc/sysconfig/network

You may wish to choose different port numbers -- these come from a successful boot of a fairly active server, and have been confirmed to not exist in /etc/services.

Comment 8 Damian Menscher 2009-02-06 17:01:47 UTC
Oops, one more:

echo "STATD_PORT=804" >> /etc/sysconfig/nfs


Note You need to log in before you can comment on or make changes to this bug.