Bug 29723 - /etc/exports not interpreting network masks correctly
/etc/exports not interpreting network masks correctly
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-27 03:52 EST by Need Real Name
Modified: 2008-05-01 11:37 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-02-27 03:52:49 EST
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:

        /net    192.168.0.0/29(rw)

    But after 'exportfs -avr' on the server, when I try mounting
    from a client who's address is 192.168.0.4, 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 192.168.0.0/28.
    But it works if I change it down to 192.168.0.0/27

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

    I'm successfully using the 192.168.0.0/29 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
to, 
    it's possible it is giving access when it isn't supposed to, which
would
    be bad.
Comment 1 Michael K. Johnson 2001-02-27 19:57:16 EST
Oops, wrong component...
Comment 2 Need Real Name 2001-03-03 08:16:46 EST
Ok, this appears to be a documentation bug.

I looked at the code, the effective source appears to be
/usr/src/redhat/BUILD/nfs-utils-0.1.9.1/support/export/client.c,
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
address. 
So the user spec should be 192.168.0.0/255.255.255.0, and not 192.168.0.0/24.

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
              address/netmask.
---

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
1.2.3.4/32.
---

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 192.168.0.0/24 is apparently being interpreted as 
192.168.0.0/0.0.0.24,  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 09:25:56 EST
Submitted bug report suggesting doc and behavior change to sourceforge.net, bug
#405655, ie:

   
https://sourceforge.net/tracker/index.php?func=detail&aid=405655&group_id=14&atid=100014

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