Red Hat Bugzilla – Bug 29723
/etc/exports not interpreting network masks correctly
Last modified: 2008-05-01 11:37:59 EDT
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.
Oops, wrong component...
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.
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