Some things on Illumos NFS export permissions
Perhaps at one point I fully understood Solaris and thus Illumos NFS export permissions (but I suspect not). If so, that understanding fell out of my mind at some point over the years since then, and just now I had the interesting experience of discovering that our NFS export permissions have sort of been working by accident.
I'll start with a ZFS
sharenfs setting and then break it down.
The two most ornate ones we have look like this:
The AAA and BBB netgroups don't overlap with
nfs_oldmail are both subsets of
The first slightly tricky bit is
root=. As the manual page explains in the NOTES section,
root= does is change the interpretation of UID 0 for
clients that are already allowed to read or write to the NFS share.
Per the manual page, 'the access the host gets is the same as when
root= option is absent' (and this may include no access).
As a corollary, '
root=NG,ro=NG' is basically the same as
ro=NG,anon=0'. Since our
root= netgroups are a subset of our
general allowed-access netgroups, we're okay here.
(This part I sort of knew already, or at least I assumed it without having hunted it down specifically in the manual page. See eg this entry.)
The next tricky bit is the interaction of
just now I would have told you that
rw= took priority over
if you had a host that was included in both (via different netgroups),
but it turns out that whichever one is first takes priority.
We were getting rw-over-ro effects because we always listed
first, but I don't think we necessarily understood that when we
wrote the second
sharenfs setting. The manual page is explicit
ro=options are specified in the same
sec=clause, and a client is in both lists, the order of the two options determines the access the client gets.
(Note that the behavior is different if you use general
See the manpage.)
We would have noticed if we flipped this around for the one filesystem
rw= groups, since the machine that was
supposed to be able to write to the filesystem would have failed
(and the failure would have stalled our mail system). But it's still
sort of a narrow escape.
What this shows me vividly, once again, is the appeal of casual superstition. I really thought I understood how Illumos NFS exports worked (and I only checked the manpage to see if it described things explicitly, and that because I was writing an entry for here). Instead I had drifted into a convenient assumption of how things were.
Sidebar: Our general narrow miss on this
We have a bunch of local programs for managing our fileservers. One of the things these programs do is manipulate NFS exports options, so that we can have a configuration file that sets general share options and then allows us to specify that specific filesystems extend them, with convenient syntax, eg:
# global share options shareopts nosuid,sec=sys,rw=nfs_ssh,root=nfs_root # our SAN filesystems: fs3-corestaff-01 /h/281 rw+=AAA
This means that /h/281 should be exported read-write to the AAA netgroup as well as the usual main netgroup for our own machines.
The actual code is written in Python and turns all of the NFS exports
options into Python dictionary keys and values. Python dictionaries
are unordered, so under normal circumstances reassembling the exports
options would have put them into some random order, so anything
ro= could have wound up in the wrong order.
However, conveniently I decided to put the NFS export options into
a canonical order when I converted them back to string form, and
sec=sys before both). There's
no sign in my code comments that I knew this was important; it seems
to have just been what I thought of as the correct canonical ordering.
Possibly I was blindly copying and preserving earlier work where
we always had