Bug 483774

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?

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

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.

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

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

(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

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