This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 483774 - nfs-utils-1.0.9-40.el5 doesn't work with tcp_wrapper/missing reverse DNS lookups
nfs-utils-1.0.9-40.el5 doesn't work with tcp_wrapper/missing reverse DNS lookups
Status: CLOSED DUPLICATE of bug 494878
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils (Show other bugs)
5.3
All Linux
low Severity urgent
: ---
: ---
Assigned To: Steve Dickson
Martin Jenner
:
Depends On: 480223
Blocks: 493631
  Show dependency treegraph
 
Reported: 2009-02-03 10:28 EST by Axel Thimm
Modified: 2013-01-10 00:02 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 480223
: 493631 (view as bug list)
Environment:
Last Closed: 2009-04-24 14:10:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Axel Thimm 2009-02-03 10:28:35 EST
+++ This bug was initially created as a clone of Bug #480223 +++

Description of the bug edited by thoger on 2009-04-06 to remove full copy of the original bug #480223, that seem to contain comments not needed here and make this bug hard to follow.  See original bug #480223 for full discussion.
Comment 1 Axel Thimm 2009-02-03 10:32:22 EST
The same fix that rejects NFS clients w/o DNS reverse lookups went into the latest RHEL5 packages as well.

For example I upgraded a RHEL5 server and all openvpn roadwarriors and other openvpn connected branches that used DNS-unregistered private IPs lost their NFS.

How can I downgrade nfs-utils on RHEL5?
Comment 3 Tomas Hoger 2009-03-31 09:28:38 EDT
(In reply to comment #1)
> The same fix that rejects NFS clients w/o DNS reverse lookups went into the
> latest RHEL5 packages as well.

Not really...  The bug you cloned is for another change to nfs-utils tcp_wrappers support, that is not part of the RHEL5 patch.

good_client in RHEL5 does:
- check if client's IP is allowed, if it is, return ALLOW
- resolve IP to hostname, if resolution fails, return DENY
- check if client's hostname is allowed, if it is, return ALLOW
- for each alias, check if alias is allowed, if it is, return ALLOW
- return DENY

good_client in broken Fedora versions:
- check if client's IP is allowed, if it is not, return DENY
- resolve IP to hostname, if resolution fails, return DENY
- check if client's hostname is allowed, if it is not, return DENY
- for each alias, check if alias is allowed, if it is not, return DENY
- return ALLOW

So if you do not have PTR records for you clients, they can only get denied if the check using only IP address already failed.  Can you post your hosts.{allow,deny}?

Related to bug #458676.
Comment 4 Warren Togami 2009-04-02 10:58:36 EDT
good_client in RHEL5 does:
- check if client's IP is allowed, if it is, return ALLOW
- resolve IP to hostname, if resolution fails, return DENY
- check if client's hostname is allowed, if it is, return ALLOW
- for each alias, check if alias is allowed, if it is, return ALLOW
- return DENY

This was the behavior in a Fedora update, but this change breaks how NFS has worked for YEARS and relies upon inherently insecure and unreliable DNS for host-based authentication.  Upstream rightly refused this behavior and Fedora reverted this.  RHEL should not follow this mistake.
Comment 5 Tomas Hoger 2009-04-02 11:21:19 EDT
(In reply to comment #4)
> This was the behavior in a Fedora update, but this change breaks how NFS has
> worked for YEARS and relies upon inherently insecure and unreliable DNS for
> host-based authentication.

Do you have an example configuration that breaks?  By default, there's not nfs-related setting in hosts.{allow,deny}, hence first hosts_ctl call returns allow and there's not attempt to resolve IP to hostname.

If you only use IP-based rules in hosts.{allow,deny}, valid clients get allowed by first hosts_ctl call, name resolution is not done.  If you IP based rules deny client, you probably do not care about being rejected due to the failed name resolution.

So the only case that should matter is allow rule with hostname and default deny rule.  In that case, when resolution fails, there's nothing to pass to subsequent hosts_ctl.

Though there may be some case I'm missing, hence my needinfo from reporter.
Comment 6 Axel Thimm 2009-04-04 12:09:04 EDT
(In reply to comment #3)
> (In reply to comment #1)
> > The same fix that rejects NFS clients w/o DNS reverse lookups went into the
> > latest RHEL5 packages as well.
> 
> Not really...  The bug you cloned is for another change to nfs-utils
> tcp_wrappers support, that is not part of the RHEL5 patch.

Well, either way, the symptoms are the same, be it a directly related bug or not. If there is no special hosts.deny/allow setup and there are no DNS PTR entries for the NFS client in now gets denied.

> So if you do not have PTR records for you clients, they can only get denied if
> the check using only IP address already failed.  Can you post your
> hosts.{allow,deny}?

They are the default ones, just comments inside.

(In reply to comment #1)
> The same fix that rejects NFS clients w/o DNS reverse lookups went into the
> latest RHEL5 packages as well.
> 
> For example I upgraded a RHEL5 server and all openvpn roadwarriors and other
> openvpn connected branches that used DNS-unregistered private IPs lost their
> NFS.

(In reply to comment #5)
> Do you have an example configuration that breaks?  By default, there's not
> nfs-related setting in hosts.{allow,deny}, hence first hosts_ctl call returns
> allow and there's not attempt to resolve IP to hostname.

See above, "random" IPs from openvon roadwarriors. I now had to add fake DNS entries to allow NFS access.

> So the only case that should matter is allow rule with hostname and default
> deny rule.  In that case, when resolution fails, there's nothing to pass to
> subsequent hosts_ctl.
> 
> Though there may be some case I'm missing, hence my needinfo from reporter.  

The case I described looks rather simple: No special tcp_wrapper configuration, e.g. just the default one and no DNS entries for the NFS client. Probably just the config you get from an out-of-the-box RHEL system.
Comment 7 Tomas Hoger 2009-04-06 09:14:56 EDT
(In reply to comment #6)
> Well, either way, the symptoms are the same, be it a directly related bug or
> not. If there is no special hosts.deny/allow setup and there are no DNS PTR
> entries for the NFS client in now gets denied.

I'm not able to reproduce this.  Here is the test I did, are you able to point out a place where it differs from your setups?

server# ifconfig eth0 | awk '/inet addr/ { print $2 }'
addr:172.19.0.224
server# rpm -q nfs-utils
nfs-utils-1.0.9-40.el5

client# ifconfig eth0 | awk '/inet addr/ { print $2 }'
addr:172.19.0.239
client# rpm -q nfs-utils
nfs-utils-1.0.9-40.el5

No PTR entries:
server# getent hosts 172.19.0.239
server# host 172.19.0.239
Host 239.0.19.172.in-addr.arpa not found: 3(NXDOMAIN)

client# getent hosts 172.19.0.224
client# host 172.19.0.224
Host 224.0.19.172.in-addr.arpa not found: 3(NXDOMAIN)

No tcp_wrappers rules:
server# grep -v -e '^#' -e '^$' /etc/hosts.*
server# 

One RO nfs share:
server# cat /etc/exports 
/export *(ro)

client# showmount -e 172.19.0.224
Export list for 172.19.0.224:
/export *

Mount from the client works fine:
client# mount 172.19.0.224:/export /mnt/
client# df -T /mnt
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
172.19.0.224:/export
               nfs    10411296    978400   8895520  10% /mnt
Comment 8 Steve Dickson 2009-04-24 14:10:06 EDT

*** This bug has been marked as a duplicate of bug 494878 ***

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