🚀 go-pugleaf

From article <343@keele.keele.ac.uk>, by cca13@seq1.keele.ac.uk (G.D. Pratt):
> I have a weird problem with setting up .rhosts files in users
> home directories so that they can do remote shells and rlogins
> without password. The setup is:

Hey gerry, you should ask the old CS guys.  We have all the answers.
(Actually I posted here and asked some months ago).

The problem is that the sequents version of NFS is too old and has bugs
in it.

Not that you wouldn't have guessed this anyway.

The fix?  Well first put up the latest release of DYNIX (hint hint)
and then find out if it's still there.  If it is then pester sequent
Europe at the unix show in London in a very loud voice.  (Mike Green
got a free lunch when he tried this tactic).
--
  ______    JANET :jonathan@uk.ac.keele.cs     Jonathan Knight,
    /       BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
   / _   __ other :jonathan@cs.keele.ac.uk     University of Keele, Keele,
(_/ (_) / / UUCP  :...!ukc!kl-cs!jonathan      Staffordshire.  ST5 5BG.  U.K.

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

>cca13@seq1.keele.ac.uk (G.D. Pratt) (cca13@seq1.keele.ac.uk, <343@keele.keele.ac.uk>):
> I have a weird problem with setting up .rhosts files in users
> home directories so that they can do remote shells and rlogins
> without password.

One thing to watch out for on NFS-mounted home directories and .rhosts
files is that the .rhosts file and all containing directories have to
be world-readable (unless the NFS filesystems are exported with root
priviledges, a no-no, imho).  Remember that rlogind and company run as
root and need to be able to read those files.

		robert
--
Robert Viduya					   robert@shangri-la.gatech.edu
Office of Computing Services
Georgia Institute of Technology					 (404) 894-6296
Atlanta, Georgia	30332-0275

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