Bug 480223

Summary: nfs-utils-1.1.4-6/7 don't work with tcp_wrapper/missing reverse DNS lookups
Product: [Fedora] Fedora Reporter: H.J. Lu <hongjiu.lu>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 10CC: axel.thimm, dcantrell, deknuydt, pwaldenlinux, rhbugzilla, rsjones, sameer.subscriptions, steved, thoger, wtogami, zboszor
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 483774 (view as bug list) Environment:
Last Closed: 2009-04-02 09:34:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 483774    
Attachments:
Description Flags
A patch none

Description H.J. Lu 2009-01-15 14:07:57 EST
I have

[hjl@gnu-13 F10]$ tail /etc/hosts.deny
#
# hosts.deny	This file describes the names of the hosts which are
#		*not* allowed to use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
ALL:ALL
[hjl@gnu-13 F10]$ tail /etc/hosts.allow 
#		See 'man tcpd' for information on tcp_wrappers
#
ALL: gnu-*.sc.intel.com
ALL: localhost
ALL: 127.0.0.1
cvspserver: *
cvs: *
svn: *
sshd: *
rsync: *
[hjl@gnu-13 F10]$ 

In support/misc/tcpwrapper.c, there are

good_client(daemon, addr)
char *daemon;
struct sockaddr_in *addr;
{
    struct hostent *hp;
    char **sp;
    char *tmpname;

        /* First check the address. */
        if (hosts_ctl(daemon, "", inet_ntoa(addr->sin_addr), "") == DENY)
                return DENY;

Since "" is passed as client_name, it only matches

ALL:ALL

in /etc/hosts.deny and doesn't match anything in /etc/hosts.allow.

Later in good_client, there are

        /* Check the official name and address. */
        if (hosts_ctl(daemon, hp->h_name, inet_ntoa(addr->sin_addr), "") == DENY)
                return DENY;

I don't think the first hosts_ctl is necessary.
Comment 1 Steve Dickson 2009-01-16 07:29:11 EST
Well I do the first hosts_ctl() call to see if IP address is allowed
If not then I go through the overhead of looking up the hostname
and checking that... I guess I'm trying to avoid always doing a 
host name lookup on every incoming packet... 

Does adding 'mountd: *' to /etc/hosts.allow (similar to you other daemons) 
work? Since the tcp_wapper code checks the hosts.allow before checking the
hosts.deny, it should...
Comment 2 H.J. Lu 2009-01-16 09:41:58 EST
(In reply to comment #1)
> Well I do the first hosts_ctl() call to see if IP address is allowed
> If not then I go through the overhead of looking up the hostname
> and checking that... I guess I'm trying to avoid always doing a 
> host name lookup on every incoming packet... 

Can you do

if (hosts_ctl () == ALLOW)
   return ALLOW;
...
return DENY?

You don't need to make the second hosts_crtl if the first hosname/address
is allowed.

> Does adding 'mountd: *' to /etc/hosts.allow (similar to you other daemons) 
> work? Since the tcp_wapper code checks the hosts.allow before checking the
> hosts.deny, it should...

That defeats the whole purpose. I want to only allow mountd from selected
hosts.
Comment 3 Steve Dickson 2009-01-16 10:36:05 EST
> if (hosts_ctl () == ALLOW)
>   return ALLOW;
>...
> return DENY?

if the above hosts_ctl() call is made with just this
IP address, the an entry like 'mountd: hostname' in the hosts.deny
will be ignored... which means a host will be allowed when it should
not, true?
 
> That defeats the whole purpose. I want to only allow mountd from selected
> hosts.

I see... I suppose these hosts are not logically organized (i.e
all on the same subnet or somthing like that) so a expandable 
list (ala netgroups) could be added to the hosts.allow...
Comment 4 H.J. Lu 2009-01-16 10:42:28 EST
(In reply to comment #3)
> > That defeats the whole purpose. I want to only allow mountd from selected
> > hosts.
> 
> I see... I suppose these hosts are not logically organized (i.e
> all on the same subnet or somthing like that) so a expandable 
> list (ala netgroups) could be added to the hosts.allow...

My hosts are on different subnets. Their IP address are obtained
via DHCP. I can set their hostnames, not their IP addresses.
Comment 5 Steve Dickson 2009-01-16 11:46:52 EST
So is netgroups an option? 

Because in the end, I think I fixed the code to  work like it should, but I do 
see that is cause you problems... Unfortunately I really don't have an answer for it...
Comment 6 H.J. Lu 2009-01-16 11:58:52 EST
(In reply to comment #5)
> So is netgroups an option?

I only allow gnu-*.sc.intel.com, which are on some random subnets.
I can only set their hostnames to gnu-*.sc.intel.com and I don't use
NIS. How does netgroups support it?

> 
> Because in the end, I think I fixed the code to  work like it should, but I do 
> see that is cause you problems... Unfortunately I really don't have an answer
> for it...

Can you add a command line option to always to do hostname lookup
so that I can add it to /etc/sysconfig/nfs?
Comment 7 H.J. Lu 2009-01-26 12:42:14 EST
Created attachment 330007 [details]
A patch

This patch uses hosts_access to properly check /etc/hosts.allow and
/etc/hosts.deny. If any optimization is desired, it should be done
in hosts_access.
Comment 8 Steve Dickson 2009-01-26 14:46:39 EST
Quesiton:

Will this patch disallow work
/etc/hosts.deny:
    mountd: <hostname>

Meaning will 'hostname' be denied with your patch?
Comment 9 H.J. Lu 2009-01-26 14:52:28 EST
(In reply to comment #8)
> Quesiton:
> 
> Will this patch disallow work
> /etc/hosts.deny:
>     mountd: <hostname>
> 
> Meaning will 'hostname' be denied with your patch?

Yes, it works as expected and I verified it. If it didn't work,
it would be a tcpwrapper bug and should be fixed properly in
tcpwrapper.
Comment 10 Steve Dickson 2009-01-26 15:15:41 EST
What happens when the hostname can't be resolved? Meaning DNS is not up
and there is no entry in /etc/hosts? Is this the mount deined?
Comment 11 H.J. Lu 2009-01-26 15:21:00 EST
(In reply to comment #10)
> What happens when the hostname can't be resolved? Meaning DNS is not up
> and there is no entry in /etc/hosts? Is this the mount deined?

When I put

mountd: fake-hostname

in /etc/hosts.deny, all hosts can mount it since fake-hostname doesn't
match any machines.
Comment 12 Steve Dickson 2009-01-28 05:59:56 EST
But the question is, when fake-hostname is a real client and 
the server can not resolve the the incoming ip address to 
'fake-hostname' (because DNS is down or there is no entry in
/etc/hosts) does the mount still succeed... 

From my testing, I see the answer is no. 

I commented out all the rules in /etc/resolv.conf, basically 
disabling DNS and added a 'mountd: <good-hostname>' entry 
to /etc/hosts.deny. 

The mount was denied to 'good-hostname' as it should...
Comment 13 Steve Dickson 2009-01-28 06:12:29 EST
After further review including a restart of mountd, with DNS disabled,
it seems the mounts to 'good-hostname' are allowed when there
is a 'mountd: <good-hostname>' entry in /etc/hosts.deny

So is seems when a IP address can not be resolve into a hostname
the mount is still allow... 

Due to the fact all the host resolving is being done by the 
tcp library code (after applying the patch in Comment #7),
I'm beginning to wonder if this is expected behaviour....
Meaning when a host lookup fails, the host is allowed access...
Comment 14 H.J. Lu 2009-01-28 09:15:01 EST
(In reply to comment #13)
> 
> Due to the fact all the host resolving is being done by the 
> tcp library code (after applying the patch in Comment #7),
> I'm beginning to wonder if this is expected behaviour....
> Meaning when a host lookup fails, the host is allowed access...

This doesn't limit to mountd.
Comment 15 Steve Dickson 2009-01-28 12:03:03 EST
True... but .... it is a hole in the access polices.... 

If host namecan not be looked up and that host name is in hosts.deny
but the mount is allowed to happen, that wrong... imho... 

Do you agree?
Comment 16 H.J. Lu 2009-01-28 12:12:55 EST
(In reply to comment #15)
> True... but .... it is a hole in the access polices.... 
> 
> If host namecan not be looked up and that host name is in hosts.deny
> but the mount is allowed to happen, that wrong... imho... 
> 
> Do you agree?

It is a DNS/tcpwrapper issue and it applies to all programs which
use tcpwrapper to control access. It should be fixed properly in
tcpwrapper.

FWIW, I deal with it using:

[hjl@gnu-13 F10]$ tail /etc/hosts.deny
ALL:ALL
[hjl@gnu-13 F10]$ tail /etc/hosts.allow 
ALL: gnu-*.sc.intel.com
ALL: localhost
ALL: 127.0.0.1
cvspserver: *
cvs: *
svn: *
sshd: *
rsync: *
[hjl@gnu-13 F10]$ 

That is I only allow trusted hosts to access my machine.
Comment 17 Warren Togami 2009-01-29 16:09:34 EST
*** Bug 480420 has been marked as a duplicate of this bug. ***
Comment 18 Warren Togami 2009-01-29 16:29:25 EST
Please also see the arguments in Bug #480420, where I argued similarly that it is wrong for nfs-utils to second guess tcp wrappers.

Ultimately it is ALWAYS a bad idea to rely upon hostnames in /etc/hosts.deny to deny access to specific hosts.  Using it that way is always a MISCONFIGURATION and the man pages should warn against it.

If one is concerned about who should be allowed access to mountd, they should use a "deny all" policy like suggested in Comment #16 and allow specific hosts in /etc/hosts.allow.  The man page should recommend this as a best practice if you really want to use tcp wrappers.

The hard coded denial upon reverse DNS failure in nfs-utils was also inconsistent with how all other tcp wrapped services behave.  Why would this be considered a bug that mountd must work around if sshd doesn't consider it a bug?  Furthermore similar misconfiguration of iptables using hostnames in rules is not considered a bug.
Comment 19 Axel Thimm 2009-01-29 16:46:03 EST
From a symptom's POV, since this was the duplicate target of bug #480420, the current sudden malfunctioning of NFS clients w/o a registered IP address in DNS is catching many people in surprise.

Even if the resulting discussion might consider this a feature than a bug, such a change is only allowed when it comes with proper warning, e.g. as release notes to F11.

Please fix this ASAP, in doubt by reversing the changes as admins run into it more and more often.

A yum update should not knock out your nfs.
Comment 20 Axel Thimm 2009-01-30 06:37:27 EST
*** Bug 481475 has been marked as a duplicate of this bug. ***
Comment 21 Steve Dickson 2009-01-31 07:00:14 EST
*** Bug 483375 has been marked as a duplicate of this bug. ***
Comment 23 Philip Walden 2009-02-02 14:59:11 EST
I followed the work-around to rollback to nfs-utils-1.1.2-7.fc9.i386.rpm and I am working again. However I am seeing the following in my message log that does not seem to prevent the mount. Is there also a unrelated selinux problem here too with rpcbind?

Feb  2 11:48:31 walden4 kernel: type=1400 audit(1233604111.162:35): avc:  denied  { read } for  pid=6379 comm="rpcbind" name="hosts.deny" dev=sda2 ino=33227820 scontext=unconfined_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file

Feb  2 11:48:31 walden4 kernel: type=1400 audit(1233604111.163:36): avc:  denied  { getattr } for  pid=6379 comm="rpcbind" path="/etc/hosts.deny" dev=sda2 ino=33227820 scontext=unconfined_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
Comment 24 Fedora Update System 2009-02-04 21:19:49 EST
nfs-utils-1.1.4-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nfs-utils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1327
Comment 25 Fedora Update System 2009-02-04 21:20:00 EST
nfs-utils-1.1.2-11.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update nfs-utils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-1331