Xref: utzoo comp.sys.sequent:628 comp.protocols.nfs:1001
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!rutgers!mephisto!prism!roy
From: roy@prism.gatech.EDU (Roy Mongiovi)
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: <10398@hydra.gatech.EDU>
Date: 12 Jun 90 20:17:52 GMT
References: <343@keele.keele.ac.uk> <36464@sequent.UUCP>
Followup-To: comp.sys.sequent,comp.protocols.nfs
Organization: Georgia Institute of Technology
Lines: 26

In article <36464@sequent.UUCP>, yuf@sequent.UUCP (Kyle Grieser) writes:
> In article <343@keele.keele.ac.uk> cca13@seq1.keele.ac.uk (G.D. Pratt) writes:
> 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.

All of this may be true, the .rhost file must be world-readable if root
has to access it as "nobody" across nfs.  However, the problem as we
occasionally see it here is somewhat different.

In our case, rlogin works fine most of the time.  There are occasions,
though, where it will anomalously request a password.  On those occasions,
if we supply a password and log in, we find that the mode 644 .rhost file
shows up in an "ls -la" but it is not accessible.  "cat" gives a write(?)
error if you try to examine the file.  "mv"ing it to a new name makes it
possible to look at the file, and it is still accessible after being moved
back to the original name.

This only happens occasionally, and we haven't been able to explain it.
-- 
Roy J. Mongiovi     Systems Support Specialist     Office of Computing Services
Georgia Institute of Technology	  Atlanta, Georgia  30332-0275   (404) 894-4660
	uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!roy
	ARPA: roy@prism.gatech.edu