How Solaris matches names in NFS exports

April 18, 2006

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.


Comments on this page:

From 128.100.49.60 at 2006-04-18 14:18:30:

To avoid those DNS vs hosts file problems, we put only the local machine IP(s) and localhost in the hosts file; everything else is looked up on DNS, and always use FQDN in /etc/dfs/dfstab shares. Performance (files vs dns) is not a problem because of the 'nscd' cache. I think the days when the whole world had to be in /etc/hosts are over. :-)

Regards - Oscar@MIE

By cks at 2006-04-18 16:03:57:

In the Linux case, we put all of the short names in the hosts file partly because we were worried about total line length limitations in /etc/exports and suchlike, given that we were dealing with around 130 machines. Using names with the full domain would have added 19 characters per machine or so (and would have made all of the files a lot more noisy).

I think this is now not a concern, if it ever really was, and certainly you can have multiple lines for an export in /etc/exports. Call it sysadmin superstition.

(We actually picked a naming scheme that let us use one or two character hostnames for the workstations (plus a subdomain), so we had more headroom just in case.)

From 128.117.8.11 at 2006-04-18 19:00:36:

Line length limits in /etc/exports are still a real problem for some OSes, especially when exporting a filesystem to about a thousand nodes in large clusters. Multiple lines per export still isn't always an option, nor does it necessarily solve the problem even when you can do it.

The natural solution to the line length being exceeded (even with short client names) is to export the filesystem to the world. Also, it's natural to forget to disallow suid binaries on the base filesystem, let alone on the mounts. Then human nature causes one to forget about the exposure.

Next, the cluster gets moved to a network accessible from a large number of other systems, at least one of which is a trivially compromisable (unwatched, unmaintained, unpatched) Linux box. Wups!

From 70.53.120.146 at 2006-04-19 08:00:44:

When I ran into the line-length limit problem in dfstab long ago, I started to split them one host per line which also makes it easier to read and edit.

share -F nfs -o rw=\
host1.domain.ca:\
host2.domain.ca:\
etc

Written on 18 April 2006.
« What do variable names mean (in Python and elsewhere)?
A gotcha with analyzing syslog logs »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Apr 18 02:03:48 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.