How Solaris matches names in NFS exports

Recently, I accidentally found out which of two options Solaris uses for matching names in NFS exports. As traditional, I did this by stubbing my toe.

Given a name in an /etc/dfs/sharetab line, there are two possible ways of checking if it matches an incoming NFS request: you could resolve the sharetab name to its IP addresses and see if the request's IP address matched, or you could take the request's IP address and try to turn it into a hostname and see if the resolved hostname is the same. There are good reasons and complexities in both approaches, and I've run into software that does name checks both ways.

(And when I wrote software that did tcpwrappers-style permissions checks I put in options to do both sorts of verification, which came in handy more than once.)

It turns out that Solaris does sharetab name checks by resolving incoming IP addresses to names (now that I look carefully at the share_nfs(1M) manpage, this is more or less implied by the phrasing of some stuff).

I discovered this by adding DNS name resolution to a system that was NFS-exporting filesystems using a sharetab something like this:

/data - nfs ro=backup,root=backup

When I added DNS name resolution to /etc/nsswitch.conf, I followed the example in the nsswitch.dns file and put 'dns' before 'files' in the hosts: entry. The NFS mount the backup server was trying to do promptly broke. While the short name 'backup' was the name of the IP address in /etc/hosts, the system was now using DNS first, and DNS said that the name of the IP address was actually 'backup.mumble.utoronto.ca'.

(I can be sure it was doing the IP to name check because a DNS lookup was happy to turn a plain 'backup' into the right IP address, due to an appropriate domain directive in /etc/resolv.conf.)

The bonus embarrassment is that our Linux nfsswitch.conf configuration is careful to check files before DNS, for much the same reason. I just didn't think about the issue when I was making the change on the Solaris machine.