Bug 3965 - portmap's man page and behavior of hosts.[allow,deny] inconsistent
portmap's man page and behavior of hosts.[allow,deny] inconsistent
Product: Red Hat Linux
Classification: Retired
Component: portmap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
Depends On:
  Show dependency treegraph
Reported: 1999-07-09 10:15 EDT by rgb
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-08-29 22:40:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description rgb 1999-07-09 10:15:12 EDT
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:


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
Comment 1 Cristian Gafton 1999-08-29 22:40:59 EDT
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.

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