Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:


should suffice to permit hosts on the private net, e.g. to nfs mount from
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:

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