[ On Sunday, September 8, 2002 at 09:33:14 (+0100), David Laight wrote: ]
> Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
>
> > > Yes - I was wondering whether that ought to be tightly enforced?
> > > ie even if a file has uid -2 it still can't be accessed?
> > 
> > Ah, _NO_!  :-)
> > 
> > > The permissions for created files become problematical...
> > 
> > Indeed!  Perhaps you should look at some clusters of diskless clients in
> > real production use.  The client superusers must quite often be able to
> > create files, and subsequently access the files they create, even on
> > partitions where they do not have superuser access (and indeed in some
> > cases they may not ever have any superuser access to any files on any
> > filesystems).
> 
> It is a long time since I've had access to such a cluster (sun3s)
> and I didn't set it up.  However under those circumstances the admin
> would almost certainly explicitely map remote root access to a
> specific local user.

I should probably point out that the NFS anonymous user is used not just
for remote client superusers, but if I understand things correctly (and
my understanding is still based more on knowledge of SunOS-4 NFS than on
the NFS implementation in NetBSD), for all "anonymous" users -- the
remote superuser is simply treated as an anonymous user.  In other words
the "-maproot" option is a mis-nomer and it would better be "-anon" just
as it was for SunOS-4 exportfs.

So, what's the difference between an explict mapping of remote client
anonymous access credentials, and the default mapping of "-2/-2"?  In
fact there is none.

The whole point is that the _default_ anonymous uid/gid for mountd(8) is
still -2/-2, even with my patch in the case where the server doesn't
have the "nfsanon" user.  Mountd must either have a default, or it must
completely and totally fail to operate.  The use of a default allows it
to continue to operate with only a minimal risk of causing problems.
That uid/gid pair is perfectly valid as a default and has been for many
years and for many systems (which makes it even more desirable to keep
as the default, eg. where there are clusters of heterogeneous servers
which can still only use those values, eg. perhaps AIX, HP-UX, etc., and
which cross-mount each other's local storage).

Your idea to have the kernel refuse any write permissions to '-2/-2' is
simply not founded in any way on the actual goals of mapping anonymous
remote client users to some local user.  The _default_ NFS anonymous
user is simply chosen so as to be well out of the way of any proper
user, even if there's no definition of this user in the local user
database, thus reducing the risk that it collide and give some remote
client undue privileges.  The choice of representation as "-2/-2" is
simply of one of convenience.  The fact remains that except for the one
reserved value needed by one(?) broken API that on a twos compliment
machine happens to match "-1", user-IDs are unsigned integer values and
so taking into account that "-1" is the same as UINT_MAX, "-2" is the
opposite end of the range of valid values farthest from the superuser at
"0".

(Note in SunOS-4 "exportfs -anon=-1" was supposed to disable all
anonymous access, and thus IIUC, access by remote client superusers
too.  I don't know if that concept is embodied in the *BSD
implementation -- it's certainly not documented.)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>