[ On Saturday, September 7, 2002 at 21:57:16 (+0100), David Laight wrote: ]
> Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
>
> A couple of little things:
> 
> > + #define DEF_ANON_GID	(-2)
> > + #define DEF_ANON_UID	(-2)
> 
> Need casting to uid_t and gid_t or gcc might start bleating

Not my GCC.  :-)

In any case I intended them to be cast when they are used, just as one
would normally do if one didn't use a pre-defined manifest constant.  I
really really really detest pre-concieved casts appearing in manifest
contant definitions, even if such constants really are only intended to
be used for one given data type.

> > + 	if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
> > + 	 /* Convert from int's to gid_t's and compress out duplicate 
> 
> getgrouplist is defined to have 'gid_t *groups' (in getgrouplist(3)
> and unistd.h, although the man page (still?) says 'the integer
> array pointed to by groups').  So this code isn't right...

That code simply copies a nearly identical fragment from further down in
the same function.....

> I've also been wondering....
> 
> I presume (from where the changes are) that this is a server-side
> map of uid zero - ie the nfs packets contain 0 not -2.

Yes, that's right.

> I was wondering whether the 'correct' fix isn't here, but is where
> file premissions are checked (access?).

No, I don't think so.  The UID/GID mapping is set up by mountd.  The
mapping for superuser->anonymous is just a special common case of the
more general mapping now also allowed by the newer '-mapall' option.

>  There uid/gid values of
> -2 could explicitly not match any user or group.

I'm sure what you mean by that.  Do you mean "their", as in "the
client's uid/gid values of -2/-2"?

If so then that's an irrelevant issue -- or rather it's a site-specific
local configuration issue, not one mountd can deal with categorically.

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.
"-2/-2" is just the de facto standard user-ID and group-ID for NFS
anonymous access, traditionally I suppose because it was the "last"
valid UID/GID possible (i.e. when treated as an unsigned integer value).

The *BSD mountd code (and probably even the original Sun implementation
too) in fact never before tried to default to some specific user (that's
what my patch essentialy tries to address), but rather made the
assumption that a user database entry for "-2/-2" would be defined by
the server administrator, if desired.  Unfortunately it's never (in any
NetBSD release) been possible to define a user with these credentials,
and I suppose the *BSD mountd assumes everyone will use either
"-maproot" or "-mapall" in all cases, even though such a requirement is
never enforced.

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.

>  So only if there
> is write access by 'other' would the values ever end up in the
> filesystem, indeed write permission could be revoked as well.

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

> There is then the question of whether specifying -mapall=nobody
> in /etc/exports should use -2:-2 or the password entry for "nobody"?

The password entry for "nobody", of course.

> Is -mapall=-2:-2 valid?

Sure (it should be, though I've not ever tried it).  Why do you think it
would not be?

> What does -webnfs do?

Damned if I know -- I've never used it!  :-)

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