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-utils | Assignee: | Steve Dickson <steved> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 10 | CC: | 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 13:34:07 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 483774 | ||||||
| Attachments: |
|
||||||
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... (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. > 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... (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. 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... (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? 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.
Quesiton:
Will this patch disallow work
/etc/hosts.deny:
mountd: <hostname>
Meaning will 'hostname' be denied with your patch?
(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. 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? (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. 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... 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... (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. 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? (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. *** Bug 480420 has been marked as a duplicate of this bug. *** 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. 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. *** Bug 481475 has been marked as a duplicate of this bug. *** *** Bug 483375 has been marked as a duplicate of this bug. *** Test Builds are at: https://admin.fedoraproject.org/updates/nfs-utils-1.1.4-8.fc10 https://admin.fedoraproject.org/updates/nfs-utils-1.1.2-11.fc9 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
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 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 |
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.