Bug 74900 - Wildcard exports export too much
Wildcard exports export too much
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Ben Levenson
: Security
Depends On:
  Show dependency treegraph
Reported: 2002-10-02 13:52 EDT by Jason Tibbitts
Modified: 2007-04-18 12:47 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-28 07:52:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

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

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

/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
Comment 1 Stephen Tweedie 2002-10-04 07:53:55 EDT
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 12:45:55 EDT
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
Comment 3 Stephen Tweedie 2002-11-11 15:40:22 EST
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-27 23:55:44 EST
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.

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