Bug 29723
| Summary: | /etc/exports not interpreting network masks correctly | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <erco> |
| Component: | nfs-utils | Assignee: | Pete Zaitcev <zaitcev> |
| Status: | CLOSED DEFERRED | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | Keywords: | 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: | 2001-03-03 14:26:05 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: | |||
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 |
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.