WHO IS NOBODY?

[Robert Thurlow]

In <1991Mar4.012943.5751 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:

>In article <1991Mar2.003208.29486 at ux1.cso.uiuc.edu>, kemp at uiatma.atmos.uiuc.edu (John Kemp) writes:
>|> Can anyone explain how the "nobody" comes into play in NFS?
>|> For example, if I put "/exportdir remotemach.subdomain" in 
>|> the /etc/exports file, how do I control who accesses that?
>|> 
>|> For example, what happens to remote users in the following cases?
>|>    root at remotemach.subdomain    ( remote super-user )

The exact behaviour depends on whether you run regular NFS with the
AUTH_UNIX flavor of RPC authentication, or Secure NFS with AUTH_DES.
Jonathan has explained it well for regular NFS; I'll obfuscate a
bit for Secure NFS.

>  Unless you have specified in /etc/exports that root is supposed to be
>trusted, uid 0 on the remote machine will map to the nobody uid on the NFS
>server.  This is a security measure to prevent people who have broken into the
>root account on the remote machine from playing around with the files on the
>NFS server.

Quite true for AUTH_UNIX, but this may not be true with AUTH_DES.  If
you run Secure NFS across two separate domains, you can arrange to map
a remote user credential to any convenient uid/gid pair.  For example,
you could map all root users from other machines to a uid/gid that
would give them the ability to access a few select files not available
to regular mortals.  This mapping happens in the "netid" database which
maps names like "unix.1993 at hismachine" to uid/gid pairs.  This is not
the general case because 1) almost nobody uses Secure NFS, and 2) when
they do, they're almost never going to figure out how to set up this
configuration.  But it can be done.

>|>    common at remotemach.subdomain  ( uname/UID/GID same on both systems )

>  Well, then, the user on the remote machine will have the same access to the
>NFS server's files as he would have if he were logged into it.  This is
>supposed to be the common case, right?

Same AUTH_DES caveat, above.

>|>    unknown at remotemach.subdomain ( known on remote, but not locally )

>  This will map to nobody on the NFS server as well.

Not true: the Sun sources do not search the password database.  They
just grab the numbers in the requests args and stuff it into the cred.
To make this more tangible, if your uid is 1993, and Jill on the next
machine happens to have a uid of 1993 on that machine, she will have
access to all of your files on any filesystem mounted from your box,
and vice versa.  AUTH_UNIX doesn't let you do any mapping except for
uid 0 (though AUTH_DES will).

>|> How can I enable universal access to "remotemach.subdomain"?

If you mean, "how can I let root at remotemach get at files as uid 0,
you can either put a "root=remotemach" setting in the /etc/exports
entry for that filesystem, or (to completely turn off the check)
you can put in a "anon=0".  The former is strongly recommended where
possible, and you should also only do it for filesystems where you
really need root access.

Rob T
--
Rob Thurlow, thurlow at convex.com
An employee and not a spokesman for Convex Computer Corp., Dallas, TX