Bug 3965 - portmap's man page and behavior of hosts.[allow,deny] inconsistent
Summary: portmap's man page and behavior of hosts.[allow,deny] inconsistent
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: portmap
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-09 14:15 UTC by rgb
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-08-30 02:40:55 UTC

Attachments (Terms of Use)

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:


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-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.

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