kemp@uiatma.atmos.uiuc.edu (John Kemp) (03/02/91)
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 )
common@remotemach.subdomain ( uname/UID/GID same on both systems )
unknown@remotemach.subdomain ( known on remote, but not locally )
How can I enable universal access to "remotemach.subdomain"?
(No YP please because it is not in use here.)
-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu
----- ( ( __) decnet - uiatmb::kemp
--- univ of illinois (_ ( __) bitnet - {uunet,convex}
-- dept of atmos sci .(____). !uiucuxc!uiatma!kemp
- 105 s gregory ave ... phone - (217) 333-6881
- urbana, il 61801 ... fax - (217) 444-4393jik@athena.mit.edu (Jonathan I. Kamens) (03/04/91)
(I've added comp.protocols.nfs to the Newsgroups of this thread, but I've left comp.unix.admin in as well, since (after all) the concept of root and uid 0 is not an integral part of the NFS protocol; it's more of a Unix thing.) 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 ) 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. |> 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? |> unknown@remotemach.subdomain ( known on remote, but not locally ) This will map to nobody on the NFS server as well. |> How can I enable universal access to "remotemach.subdomain"? Whta do you mean by "universal access?" -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
thurlow@convex.com (Robert Thurlow) (03/04/91)
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