Bug 203706 - clients are not allowed to access portmap or NFS
Summary: clients are not allowed to access portmap or NFS
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-securitylevel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris Lumens
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-23 11:23 UTC by G.Wolfe Woodbury
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-12 18:27:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description G.Wolfe Woodbury 2006-08-23 11:23:19 UTC
Description of problem:
Under the default rules provided by s-c-securitylevel with NFSV4 checked
(allowed) client machines cannot access NFS services.


Version-Release number of selected component (if applicable):
iptables-1.3.5-1.2
s-c-securitylevel-1.6.16-3

How reproducible:
always


Steps to Reproduce:
1.
2.
3.
  
Actual results:
client machine (Fedora development) cannot access portmap or NFS. Reports
(wrongly) "No Route To Host".

Expected results:
rpcinfo and NFS should work


Additional info:

turning off iptables or adding a network "accept" for the LAN allows rpcinfo
and NFS to work.  Trying to add a udp accept for portmap does *not* allow
rpcinfo to work. Netstat shows active listeners in place for the concerned
services.  The turning off of iptables is not a good alternative.

Comment 1 Thomas Woerner 2006-08-23 14:50:23 UTC
Assigning to system-config-securitylevel which generates the firewall config file.

Comment 2 Chris Lumens 2006-09-15 16:02:41 UTC
I'm having nothing but machine lockups trying to test NFSv4 stuff here recently.
 Any ideas what the problems in the current firewall setup are?  Which ports do
I still need to open?

Comment 3 G.Wolfe Woodbury 2006-09-16 03:04:13 UTC
Well, portmapper(sunrpc) needs to be opened at least.
Additionally the rpc.mountd, and probablt rpc.nfslockd ports too.

Here, I punted and added a firewall rule for the local lan as a trusted source.
I'm inside a router/firewall, so I feel (somewhat) safe in doing this; also I'm
using a non-routable set of addresses for the lan (10.x.x.x)

I've been playing tonight with a variety of ports, but the nfs init.d script is
trying to use some /proc/fs/nfs entries that don't exist (nlm_<something>) to
configure ports and such.  The /etc/sysconfig/nfs file probably needs to be
created and setup some relatively static ports for the lockd and mountd daemons.

The inherent flexibility of the rpc/portmapper mapping makes some of the static
nature of the firewalling process a real problem to overcome.

As far as the NFSv4 stuff, I'm having no problems with NFS on the i686 boxes
that I'm using for the testing.  I'm not sure that I'm using v4, so take it with
a grain of salt.


Comment 4 Chris Lumens 2006-09-20 20:43:42 UTC
It looks to me like you are not using NFSv4 here.  I was finally able to get a
machine set up that doesn't panic, and ran some tests.  I set up an NFS server
with ssh and nfsv4 ports open, and a client with only the ssh port open.  Then:

# mount exeter:/home/clumens/nfs /misc/
mount: mount to NFS server 'exeter' failed: System Error: No route to host.

# mount -t nfs4 exeter:/ /misc/
# mount | grep exeter
exeter:/ on /misc type nfs4 (rw,addr=172.16.80.157)

The difference in paths I'm attempting to mount is intentional - that's the way
things work with NFSv4.  Since the checkbox does clearly say "NFSv4", I'm
inclined to say this is not actually a bug.

Comment 5 Chris Lumens 2006-10-12 18:27:32 UTC
Closing based on my previous comments.  If you disagree and think this is still
a bug, feel free to repoen and explain what you think I should do to clear it up.

Comment 6 Christian Nolte 2007-03-07 10:21:04 UTC
Perhaps it would be an option to add a checkbox for "NFS legacy" or something
like that?


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