[ On Saturday, September 7, 2002 at 22:58:15 (+0100), David Laight wrote: ]
> Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
>
> On Sat, Sep 07, 2002 at 05:30:07PM -0400, Greg A. Woods wrote:
> > Not my GCC.  :-)
> 
> No, but the new one Jason is playing with might.
> It generated rather a lot of signed/unsigned warnings he's been fixing.

Not if they are cast when used, as intended.

Of course in fact they're only used in assignments and a syslog() (well
they're used in a syslog() in my even newer code :-), so even then I
doubt even GCC 3.2 will complain, and if it does then casts can be added
as required and appropriate.

> > In any case I intended them to be cast when they are used,
> 
> Why? I actually dislike casts - they are too powerful for most places [1].

You can dislike them if you like but they're much better used where
necessary and I don't think they should ever be encoded into a manifest
constant defintion as you were suggesting they should be!  I really
dislike _unnecessary_ casts.

> Since these are constants of type uid_t they really ought to be in
> the domain of the type.

Actually they're in the domain of (int), which is what I intended.

>  Otherwise you might as well just use -2, at
> least then it is obvious what is going on....

No, they're used in multiple places -- _I_ definitely want a manifest
constant integer to use, not some magic number.
 
> > The mountd code needs to have some kind of default just in case the
> > local user database doesn't contain a "nobody" (or whatever) user.
> 
> No: the default (checked man page again) is -maproot=-2:-2
> not -maproot=nobody.

Please go read the mountd.c code, and please go read the entire PR., not
just the submission I added to it today.

Please also read the patched (with todays patch) manual page too.

The mountd code needs to have some default uid and gid to use in case
the local user database doesn't contain a "nobody" (or "nfsanon", or
whatever) user.  That means not only for my patched version which will
try to first find an "nfsanon" user, but also for the pre-patched and
default case where "-2/-2" is used.

> > It's really irrelevant what any client might have as a user or group for
> > the ID "-2".  In a configuration set up as intended by the original
> > implementers I suppose the user and group databases would be shared via
> > NIS/YP, but all that really matters is the server be able to map
> > accesses by client superusers into some non-superuser ID.
> 
> Does NFS predate NIS/YP?  It could easily ...

Perhaps, but regardless the appearance of NIS/YP is in part directly to
address these kinds of issues (i.e. centralized management of UIDs that
will be seen by multiple clients on distributed filesystems).
 
> > The general idea behind the NFS anonymous user is to map access
> > credentials from remote superusers into some local UID which in general
> > is least-privileged (i.e. owns no files and thus can only write to
> > world-writable places).
> 
> 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).

-- 
								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>