Bug 494585 - libwrap - Nor ip, nor hostname work,, only when used ALL expression in hosts.deny access is denied
libwrap - Nor ip, nor hostname work,, only when used ALL expression in hosts....
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils (Show other bugs)
4.8
All Linux
low Severity urgent
: rc
: ---
Assigned To: Steve Dickson
BaseOS QE
: Regression
Depends On:
Blocks: CVE-2008-4552
  Show dependency treegraph
 
Reported: 2009-04-07 10:54 EDT by Jan Ščotka
Modified: 2009-05-20 08:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 15:02:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Ščotka 2009-04-07 10:54:17 EDT
------------
There is problem with tcp_wrappers 
Both IP adress and hostname is not work properly.
Only when ALL is used, it works
when used in hosts.deny
mountd:ALL
statd:ALL
everything work as expected

when used (where ip is ip adress of client (where runned mount command)
mountd: 10.16.40.140
statd: 10.16.40.140

then nfs export is mounted (shouldn't be)

Actual result:
export mounted

Expected:
access denied by tcp_wrappers

----------------------------------------
Second problem

copied from bz 493631

Description of problem:
I tested support by tcp wrappers,
And it seems to be okay, until used mount locally,

in hosts.deny is
mountd:ALL
statd:ALL

hosts.allow is empty

exports contain
/tmp *(ro,sync)

then
# mount ppcp-4as-v1.lab.bos.redhat.com:/tmp /mnt
When I tried it from another machine, everting was ok, (RPC Error:
Authentication error.)

But when I used same command on computer where nfs running, mount is succesful
(but shouldn't be)


I'm not sure if it is caused by DNS hostnames (because there is ALL in
hosts.deny) But I think, this bug shoud be fixed (not all host lookup).
In case of question, please ping me on irc #qa #urt #devel
Comment 1 Tomas Hoger 2009-04-07 11:40:09 EDT
(In reply to comment #0)
> when used (where ip is ip adress of client (where runned mount command)
> mountd: 10.16.40.140
> statd: 10.16.40.140

This should be a consequence of incorrect use of tcp_wrapper by nfs-utils.  See bug #458676 for details, there should be similar case mentioned in comment 11.

> But when I used same command on computer where nfs running, mount is succesful
> (but shouldn't be)

As noted in https://bugzilla.redhat.com/show_bug.cgi?id=493631#c10 , all local access is permitted by nfs-utils regardless of tcp_wrappers configuration.  This seems to be a design decision, that we may not want to change.
Comment 3 Jan Ščotka 2009-04-07 12:07:32 EDT
It can be, but dont know.
Now I tested various configuration.
When I used
mountd:ALL
statd:ALL
in hosts.deny
connection was refused

when I add
mountd:10.16.40.140
statd:10.16.40.140
into hosts.access
As expected I can connect nfs export.

This look like, the problem is only when hosts.deny is used
Comment 4 Tomas Hoger 2009-04-07 12:29:18 EDT
(In reply to comment #3)
> when I add
> mountd:10.16.40.140
> statd:10.16.40.140
> into hosts.access
> As expected I can connect nfs export.
> 
> This look like, the problem is only when hosts.deny is used  

See https://bugzilla.redhat.com/show_bug.cgi?id=458676#c11 for the explanation.
Comment 5 Jan Ščotka 2009-04-07 12:39:25 EDT
Strange behaviour :-)
Comment 6 Steve Dickson 2009-04-09 06:15:12 EDT
With Respect to Comment #3, using the -93 nfs-utils package, both
hostnames and IPaddress now do indeed work in the hosts.deny files.
At least thats what my testing showed..
Comment 12 errata-xmlrpc 2009-05-18 15:02:23 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-0955.html

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