Bug 29723 - /etc/exports not interpreting network masks correctly
Summary: /etc/exports not interpreting network masks correctly
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-27 08:52 UTC by Need Real Name
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-03 14:26:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-02-27 08:52:49 UTC
I think I found a security problem in NFS where it isn't
    parsing network ip ranges correctly. According to exports(5)
    the "address/netmask" syntax is supported.

    I noticed this while configuring an upgraded www/nfs server 
    to only allow machines 192.168.0.[0-7] to access the 
    servers' services. 

    To do this, I'm using in /etc/exports:


    But after 'exportfs -avr' on the server, when I try mounting
    from a client who's address is, I get:

        # mount -t nfs server:/net /mnt/net
        mount: tahoe:/net failed, reason given by server: Permission denied

    The same thing happens if I change the mask to
    But it works if I change it down to

    Seems to me both /28 and /29 should allow the .4 machine to access 
    the server, shouldn't it?

    I'm successfully using the mask for xinetd and apache..
    Seems like only NFS is the problem.

    I figure if in this case, nfs isn't giving access when it's supposed
    it's possible it is giving access when it isn't supposed to, which
    be bad.

Comment 1 Michael K. Johnson 2001-02-28 00:57:16 UTC
Oops, wrong component...

Comment 2 Need Real Name 2001-03-03 13:16:46 UTC
Ok, this appears to be a documentation bug.

I looked at the code, the effective source appears to be
lines that read:

        if (clp->m_type == MCL_SUBNETWORK) {
                char    *cp = strchr(clp->m_hostname, '/');

                *cp = '\0';
                clp->m_addrlist[0].s_addr = inet_addr(clp->m_hostname);
                clp->m_addrlist[1].s_addr = inet_addr(cp+1);
                *cp = '/';

Assuming I'm looking at the effective code, this clearly shows the intention 
is that the value on either side of the '/' is being parsed as a complete ip
So the user spec should be, and not

exportfs(5) reads:

       IP networks
              You  can also export directories to all hosts on an
              IP (sub-) network simultaneously. This is  done  by
              specifying  an  IP  address  and  netmask  pair  as

I suggest that is confusing, and needs clarification, esp. in light
of the xinetd.conf(5) page, which uses the same terminology
("address/netmask") to qualify the *other* way to specify masks, eg:

     only_from  [..]
                        e)   an ip address/netmask range  in  the form of

At least xinetd.conf() include a non-ambiguous example.

It seems there is confusion in the industry as to what an 'address/netmask' 
spec is. Entering is apparently being interpreted as,  due to the behavior of inet_addr(), an apparently 
valid spec with a very wrong behavior WRT to the intention.

To remove any ambiguity, an example absolutely must be given. 
It's also debatable whether the software should allow a single number 
to follow the '/' if an ip address is expected. A check for '.' in the rhs value 
should trigger an error if not present.

Comment 3 Need Real Name 2001-03-03 14:25:56 UTC
Submitted bug report suggesting doc and behavior change to sourceforge.net, bug
#405655, ie:


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