2006-04-18
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.