Bug 3965

Summary: portmap's man page and behavior of hosts.[allow,deny] inconsistent
Product: [Retired] Red Hat Linux Reporter: rgb
Component: portmapAssignee: David Lawrence <dkl>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: rgb
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-08-30 02:40:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description rgb 1999-07-09 14:15:12 UTC
The portmap man page (and the man pages for
hosts.[allow,deny]) clearly state that authentication should
occur with the FIRST line found that matches the service
or daemon with the host or network or group.  It also states
that it checks hosts.allow first, then hosts.deny.  Thus:

ALL:	ALL

in hosts.deny accompanied by:

portmap:	.rgb.private.net

should suffice to permit hosts on the private net, e.g.
eve.rgb.private.net to nfs mount from adam.rgb.private.net
while denying access to the portmapper (and everything else)
to all hosts outside the private network.

It doesn't.  hosts on the private network are denied access
by adam's portmapper unless the hosts.deny line is
something like:

ALL EXCEPT:	portmap:	.rgb.private.net

This is "fine" and it is arguably more secure to have
hosts.deny and hosts.accept be perfect compliments of one
another, but it isn't the way it is documented and is very
difficult to figure out (I had to run portmap -d to document
the behavior).  So you should fix the way/order portmap
parses these files OR you should fix the various man pages.

   Robert G. Brown
   rgb.edu

Comment 1 Cristian Gafton 1999-08-30 02:40:59 UTC
Try using
	tcpdmatch portmap foo.your.domain.name
after you've set up the rules for it; it should tell you exactly and
why it is happening as far as the tcp_wrappers are concerned.