Xref: utzoo comp.unix.admin:1125 comp.protocols.nfs:1867 Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!convex!thurlow From: thurlow@convex.com (Robert Thurlow) Newsgroups: comp.unix.admin,comp.protocols.nfs Subject: Re: WHO IS NOBODY? Message-ID: Date: 4 Mar 91 03:53:07 GMT References: <1991Mar2.003208.29486@ux1.cso.uiuc.edu> <1991Mar4.012943.5751@athena.mit.edu> Sender: usenet@convex.com (news access account) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 65 Nntp-Posting-Host: dhostwo.convex.com In <1991Mar4.012943.5751@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1991Mar2.003208.29486@ux1.cso.uiuc.edu>, kemp@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@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@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@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@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@convex.com An employee and not a spokesman for Convex Computer Corp., Dallas, TX