Xref: utzoo comp.sys.sequent:622 comp.protocols.nfs:992
Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!sequent!yuf
From: yuf@sequent.UUCP (Kyle Grieser)
Newsgroups: comp.sys.sequent,comp.protocols.nfs
Subject: Re: .rhosts problem with NFS mounted home directory - is it real?
Keywords: NFS rsh rlogin passwd .rhosts
Message-ID: <36464@sequent.UUCP>
Date: 8 Jun 90 23:07:27 GMT
References: <343@keele.keele.ac.uk>
Reply-To: yuf@crg2.UUCP (Kyle Grieser)
Organization: Sequent Computer Systems Inc.
Lines: 25

In article <343@keele.keele.ac.uk> cca13@seq1.keele.ac.uk (G.D. Pratt) writes:
> manufacture was involved. Someone else here said they that the "stat" call
> was failing - ie at the time of the "rsh" or "rlogin" call the ".rhosts"
> file didn't appear to be there.

This is partially true.  When NFS goes across the wire to the server
machine, it goes as "root" (/usr/ucb/{rlogin, rsh} are setuid "root"). 
NFS maps "root" to the userid "nobody" on the server machine, and "nobody"
is usually a non-privileged userid.  Since the .rhosts file is not (or
shouldn't be) readable by the world, a non-privileged user cannot look
at the file.  This is what is causing the failure of "rlogin" and "rsh"
for those users that have read permission (on their .rhosts files and/or
home directories) denied to others.  One workaround is to give world
read permission for .rhosts, but this isn't suggested as it could
compromise security.

The solution is not to have the client machine look for the .rhosts file 
as "root", but as the user in question.  This is currently an outstanding
bug against Dynix.

----
Kyle Grieser				...!sequent!yuf
Sequent Computer Systems Inc.		sequent!yuf@uunet.uu.net
15450 S.W. Koll Parkway
Beaverton, OR 97006			(503) 626-5700