2009-07-30
How we do custom NFS mount authorization on Solaris 10
Suppose that you want to use some custom method of authenticating and
authorizing NFS mounts, and that your fileservers are Solaris 10 systems
(although the same general approach could probably work elsewhere).
Further suppose that you don't have the source to mountd, or at least
don't want to modify it for various sensible reasons. Fortunately,
there is an evil hack that you can commit that will let you do whatever
authorization checks that you need.
(When thinking about all of this, remember that NFS mount security has limits.)
Solaris, like most systems, will let you export filesystem to (NIS)
netgroups. Solaris also has an /etc/nsswitch.conf file to specify how
netgroups (among other things) are looked up (in fact it originated the
idea). And finally, one of the little-used features of nsswitch.conf is
that you can write your own library to be a new lookup service (that you
can then use in nsswitch.conf).
So, the evil hack is to hijack mountd's netgroup lookups to do your own
authorization by having your own custom library set as the service for
netgroups in nsswitch.conf. When you export a filesystem to a netgroup
and a client tries to mount the filesystem, mountd will wind up
calling innetgr() to see if the machine is in the netgroup, which will
wind up calling a function in your lookup service library, and this
function can use whatever mechanism you want to decide whether to say
yes or no.
(Essentially what you're doing is hijacking 'netgroups' to pass magic
tokens through mountd to your authorization library. Note that your
library will get the same information that innetgr() does, which gives
it both the client host and the netgroup name.)
One drawback of this approach is that your authorization library must
perform all of the authorization checking, because you can't tell
mountd to export something to host X but only if it's also in netgroup
Y.
We use this here on our Solaris 10 fileservers,
and it works fine (with some caveats that don't fit in this
entry). The basic idea can probably be applied on any Unix with an
/etc/nsswitch.conf and enough documentation on it to let you write
new lookup services.
(The usual disclaimer: I didn't come up with this, I'm just writing it up.)
Sidebar: ways to use this
There are two ways that I can think of for using this:
- for extended host authentication;
you have some mechanism to have netgroup-like lists of machines,
but you do additional verification that the IP address actually
is the real host instead of an imposter.
You'll have groups of machines in 'netgroups', and export things
to various different netgroups, and it will all look quite normal
to the casual observer.
- to have a completely new authorization system. Here the only thing the netgroup names are used for is so that your own authorization system knows what it's being asked to authorize.
Our use of this is the first sort, for extended host authentication.