rsh and nfs home directory

[Michael I. Bushnell]

In article <10730 at pollux.UUCP> jgd at pollux.UUCP (Dr. James George Dunham) writes:
>
>	We are running 4.3 + NFS from Mt. Xinu on some 750's and uVAX-II.
>I recently split up the /usr2 (user) file system across machines and 
>then used NFS to network then together as a single /usr2 directory. I
>have discovered a problem when a regular user attempts to do a remote
>command to a machine where his home (login) directory is on an NFS
>mounted directory, i.e., another machine physically has his files. The
>command fails with "permission denied". Further background is that root
>does not have superuser priviliges on NFS mounted file systems. The
>machines are set to run with each other being an equivalent host. The
>problem appear with and without yellow pages running. Further, the
>user has a .rhosts file with the other machine given permission to
>execute remote commands. I admit I have not spent much time digging
>into the problem, but perhaps someone else has observed the problem
>and can provide a solution. Thanks for any help.
>				-Jim Dunham
>				 pollux!jgd



First off, root (by default) does not have root on remote machines,
instead, uid 0 is mapped to "nobody" (defined in nfs/nfs_server.c),
which is -2 by default.  If you trust everyone who you export to, and
everyone who is root on your network and clever, then you can set this
to 0, and your problem goes away.

Failing that, the problem seems to be that the remote machine is
unable (as root) to read the users .rhosts file.  Solution:  tell all
your users to make their home directories publicly searcheable (if not
readable) and their .rhosts file to be publicly readable.

hosts.equiv has no bearing on the mapping of 0 to nobody by the nfs
server.



-- 
                N u m q u a m   G l o r i a   D e o 

			Michael I. Bushnell
			HASA - "A" division
			mike at turing.unm.edu
	    {ucbvax,gatech}!unmvax!turing.unm.edu!mike