Bug 494585 - libwrap - Nor ip, nor hostname work,, only when used ALL expression in hosts.deny access is denied
Summary: libwrap - Nor ip, nor hostname work,, only when used ALL expression in hosts....
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils
Version: 4.8
Hardware: All
OS: Linux
low
urgent
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: CVE-2008-4552
TreeView+ depends on / blocked
 
Reported: 2009-04-07 14:54 UTC by Jan Ščotka
Modified: 2009-05-20 12:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-18 19:02:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:0955 0 normal SHIPPED_LIVE Moderate: nfs-utils security and bug fix update 2009-05-18 13:24:03 UTC

Description Jan Ščotka 2009-04-07 14:54:17 UTC
------------
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 15:40:09 UTC
(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 16:07:32 UTC
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 16:29:18 UTC
(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 16:39:25 UTC
Strange behaviour :-)

Comment 6 Steve Dickson 2009-04-09 10:15:12 UTC
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 19:02:23 UTC
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.