Bug 74900

Summary: Wildcard exports export too much
Product: [Retired] Red Hat Linux Reporter: Jason Tibbitts <j>
Component: nfs-utilsAssignee: Stephen Tweedie <sct>
Status: CLOSED UPSTREAM QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-03-28 12:52:33 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:

Description Jason Tibbitts 2002-10-02 17:52:35 UTC
I just found that a wildcard export in /etc/exports will give access to more
hosts than it is documented to.  From exports(5):

wildcards
Machine names may contain the wildcard characters * and ?.  This  can  be  used
   to make the exports file more compact; for instance, *.cs.foo.edu matches all
hosts in the domain cs.foo.edu. However, these wildcard characters do not match
the dots in a  domain name, so the above pattern does not include hosts such as
a.b.cs.foo.edu.

However, I've fond that the last sentence is untrue.  I have this in /etc/exports:

/export/spool   *.math.uh.edu(rw)

and I can simply mount this directory from the host d182.dhcp.math.uh.edu:

showmount -a|grep dhcp
d182.dhcp.math.uh.edu:/export/spool

/var/log/messages on the server has:

Oct  2 12:28:34 util2 rpc.mountd: authenticated mount request from
d182.dhcp.math.uh.edu:641 for /export/spool (/export/spool)

and of course I can mess with any user's files just by getting a DHCP address. 
Not that NFS is in any way secure, but now the hole is, well, so big that there
isn't much wall.

Tested with nfs-utils 0.3.3-5, but the bug goes back at least to Red Hat 6.2
(more specifically, the modified version that Scyld ships as part of the Beowulf
distribution).

Comment 1 Stephen Tweedie 2002-10-04 11:53:55 UTC
I suspect that this is a documentation bug rather than an implementation bug ---
I think the actual behaviour is intended.  I'll check upstream to see whether
it's the documentation or the implementation which needs fixing, but I expect
that many, many sites rely on the existing behaviour.

Comment 2 Jason Tibbitts 2002-10-04 16:45:55 UTC
That would be somewhat disturbing, as it's equally possible that sites think
they're getting the documented behavior and are insecure.  If not fixed, there
would seem to be no way to get something like the documented behavior.

Some possibilities:

Add an additional wildcard that gives the documented behavior.

Supporting a richer pattern matching language (regexp or somesuch).

Allow an explicit "not export to subdomains" option somehow.

Or just nudge me in the proper direction to fix this locally.  I don't like to
carry around local patches but in this case I really do have to have this
functionality.

Comment 3 Stephen Tweedie 2002-11-11 20:40:22 UTC
I pushed this upstream to get people to discuss whether the implementation or
the documentation is correct here, but there's been no response so far.  I'm
going to push the bug to NEEDINFO until I get some idea of which is the right
way to go, since there's no way we can depart from upstream behaviour in this case.

Comment 4 Jason Tibbitts 2003-03-28 04:55:44 UTC
nfs-utils 1.0.2 effectively resolves this by changing the documentation to match
the current behavior.  Unfortunately it doesn't document what happens when more
than one wildcard matches a host, or how to explicitly not export a host that is
otherwise matched.  (Orthogonality suggests an empty option list, but this
doesn't work.)

The best I can come up with is the following, to export to all hosts except
those that start with 't':

/export      *.dhcp.math.uh.edu(ro,all_squash) *.math.uh.edu(rw)

but that still gives read access to some files.

So I suppose this bug should be closed, as there's no real bug per se once
1.0.2+ get into Red Hat.  I'll try to pursue the missing functionality issue
directly with the NFS folks.