- A flaw was found in the way nfs-utils performed IP based authentication of mount requests. In configurations where a directory was exported to a group of systems using a DNS wildcard or NIS (Network Information Service) netgroup, an attacker could possibly gain access to other directories exported to a specific host or subnet, bypassing intended access restrictions.
- It was found that the mount.nfs tool did not handle certain errors correctly when updating the mtab (mounted file systems table) file. A local attacker could use this flaw to corrupt the mtab file.
- The function responsible for parsing the /proc/mounts file was not able to handle single quote characters (') in the path name of a mount point entry if the path name contained whitespaces. As a consequence, an NFS-exported file system with such a mount point could not be unmounted. The parsing routine has been modified to parse the entries in the /proc/mounts file properly. All NFS file systems can be now unmounted as expected.
- On an IPv6-ready network, an NFS share could be mounted on the same location twice if one mount failed over from IPv6 to IPv4. This update prevents the failover to IPv4 under such circumstances.
- Prior to this update, NFS IPv6 unmounting failed. This happened because the umount command failed to find the respective mount address in the /proc/mounts file as it was expecting the mount address to be in brackets; however, the mount command saves the addresses without brackets. With this update, the brackets are stripped during the unmount process and the unmount process succeeds.
- Prior to this update, the system returned a misleading error message when an NFS mount failed due to TCP Wrappers constrictions on the server. With this update, the system returns the "mount.nfs: access denied by server while mounting" error message.
- The showmount command caused the rpc.mountd daemon to terminate unexpectedly with a segmentation fault. This happened because showmount requested a list of clients that have performed an NFS mount recently from the mount link list with an RPC (Remote Procedure Call) message sent to the daemon. However, the mount link list was not initialized correctly. With this update, the mount link list is initialized correctly and the problem no longer occurs.
- Mounting failed if no NFS version ("nfsvers") was defined. Also, the system returned no error message when the NFS version was specified incorrectly. With this update, the system returns the following error in such cases: "mount.nfs: invalid mount option was specified."
- The "showmount -e" command returned only the first client that imported a directory. This occurred due to an incorrect filtering of group names of clients. This bug has been fixed and the command returns all hosts, which import the directory.
- The nfs-utils manual pages did not contain description of the "-n" command-line option. This update adds the information to the rpc.svcgssd(8) man page.
- Due to an incorrect library order at link time, building nfs-utils from the source package resulted in a non-functional rpc.svcgssd daemon. This update reorders libgssglue in the spec file and the daemon works as expected in this scenario.
- Prior to this update, the rpcdebug tool run with the "pnfs" flag failed over to "nfs". This update adds the pNFS and FSCache debugging option and the problem no longer occurs.
- The debuginfo file for the rpcdebug binary was missing in the debuginfo package because the spec file defined the installation of the rpcdebug tool with the "-s" parameter. The parameter caused the binary to be stripped of debugging information on installation. With this update, the spec file was modified and the debuginfo file is now available in the debuginfo package.
- The rpc.idmapd daemon occasionally failed to start because the /var/lib/nfs/rpc_pipefs/ directory was not mounted on the daemon startup. With this update, the startup script checks if the directory is mounted.
- This update adds details about exports to specific IPv6 addresses or subnets to the exports(5) manual page.
- Previously, the nfsd daemon was started before the mountd daemon. However, nfsd uses mountd to validate file handles. Therefore, if an existing NFS client sent requests to the NFS server when nfsd was started, the client received the ESTALE error causing client applications to fail. This update changes the startup order of the daemons: the mountd daemon is now started first so that it can be correctly used by nfsd, and the client no longer receives the ESTALE error in this scenario.