View Issue Details

IDProjectCategoryView StatusLast Update
0017067CentOS-8nfs-utilspublic2020-02-18 20:20
Status newResolutionopen 
Product Version8.1.1911 
Target VersionFixed in Version 
Summary0017067: The 'insecure' option appears to be incorrectly processed for [world] and overlapping IP ranges in /etc/exports
DescriptionGiven the following /etc/exports file, per the documentation, I would expect that connections from would be allowed to connect from ports above 1024 and all other hosts would be required to connect from 'secure' ports.

/srv/nfs_share *(sync,sec=sys,anonuid=65534,anongid=65534)

However, what I've found is that, unlike all other options, the 'insecure' option is overridden by *any* other instance of overlapping IP addresses (including the wildcard).

For instance, the following will also cause a mount failure if the client is using a port over 1024:


The following configuration functions properly so it appears to be a processing issue specific to wildcard and netmask ordering with the 'secure' option. No other option appears to be affected from some basic testing:


In this case, I was using 'stunnel' to set up a connection, which is a common configuration for encrypting NFS shares and would like to have the default be 'secure' with only stunnel connections allowed to connect as 'insecure' but this is simply not possible.
Steps To Reproduce# On the NFS Server
1. mkdir /srv/nfs_share
2. Create /etc/exports with the following content:

/srv/nfs_share *(sync,sec=sys,anonuid=65534,anongid=65534)
3. exportfs -ra

# On the NFS Client
1. ssh -L 12345: fqdn.of.server

## In a new window
2. mount -vvv -t nfs4 -o port=12345,hard,intr,sec=sys /mnt
Additional InformationAlso occurs on EL7 and EL6.

Current package versions:

* nfs-utils-1.3.0-0.65.el7.x86_64
* kernel-3.10.0-1062.12.1.el7.x86_64
Tagsnfs, secure


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2020-02-18 20:20 trevor.vaughan New Issue
2020-02-18 20:20 trevor.vaughan Tag Attached: nfs
2020-02-18 20:20 trevor.vaughan Tag Attached: secure