Bug 473964 - mount daemon port random, so iptables can't be used by default
mount daemon port random, so iptables can't be used by default
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-01 11:35 EST by Daniel Veillard
Modified: 2009-06-11 11:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-11 11:24:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Veillard 2008-12-01 11:35:49 EST
Description of problem:
the port used by rpc.mountd is randomized by default, as a result
it's impossible to add it to the firewall tables when asking to open NFS
port.

Version-Release number of selected component (if applicable):
nfs-utils-1.1.2-6.fc9
also in 
nfs-utils-1.0.9-35z.el5_2 in RHEL

How reproducible:
systematically

Steps to Reproduce:
1. /etc/init.d/nfs start
2. netstat -ulpn
3. see the port for mountd it's not a predefined one
  
Actual results:
get a random port.

Expected results:

get a predefined port, get the system-config-securitylevels
to open that port when asking to open NFS

Additional info:
This prevent using iptables when setting up and NFS server unless
one manage to guess why the mount packets are filtered out and how
to fix this in a stable way
Comment 2 Steve Dickson 2008-12-01 13:15:46 EST
It is true, by default, rpc.mountd does bind to random ports,
but rpc.mountd can be tied to a particular port by using the
"--port" option. The easiest way would be to set the RPCNFSDARGS 
variable in /etc/sysconfig/nfs.

Is there a reason the --port option can not be used?
Comment 3 Rik van Riel 2008-12-01 13:48:51 EST
Is there a reason it is not used by default? :)
Comment 4 Daniel Veillard 2008-12-01 15:12:29 EST
It took me a while to find out there was a random port which needed
to be added to iptables, then to find out it was random and how to
fix it in /etc/sysconfig/nfs . There is also a number of other random
port which might be set up in that config file.
Basically I really didn't want to just drop down iptables but that
was by very far the easiest way. We should not put users in front of
the dilemna of chasing out random port needed by undocumented servers
or just drop security. I think it's our dutie to allow NFS to work
once the user has selected NFS in system-config-securitylevels firewall
setting. And that requires a fixed port by default as far as I understand.

Daniel
Comment 5 Steve Dickson 2008-12-02 06:31:06 EST
> Is there a reason it is not used by default? :)
What should the defaults be?? As soon as we hard code
a port and daemons start failing because they can't
bind to that port (due to the fact its not free) will
not be good either... 

> I think it's our dutie to allow NFS to work once the user has selected NFS in 
> system-config-securitylevels firewall setting. And that requires a fixed port 
> by default as far as I understand.
Not so much "fixed" ports but registered ports similar to the ones in
/etc/services. That way each daemon could do a getservbyname() call and
find out which port it should use. But then again, what happens if that 
port is taken and the bind fails? Should the daemon try for another
port or just fail?
Comment 6 Bug Zapper 2009-06-09 06:03:37 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Steve Dickson 2009-06-11 11:24:42 EDT
I'm going to close this as not a bug since there are ways
to set static port number which do seem to work.

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