cca13@seq1.keele.ac.uk (G.D. Pratt) (06/07/90)
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: - Sun 3/50s running SunOS 3.5 - Sequent Symmetry running DYNIX(R) V3.0.15 NFS #4 - users home directories on the Sequent are NFS mounted on the Suns from /etc/fstab as: seq1:/u2 /u2 nfs rw,hard,retrans=6,bg,noquota 0 0 - when users have a valid .rhosts file in their home directory thet get "Permission denied" for "rsh" and need to give a password for "rlogins" - other users, ie ME, have their home directory on the suns - which is NFS mounted off a Sun 3/180 server. With the same information in the .rhosts file I can do "rsh" and "rlogin" with no problem. When I contacted Sun a while ago about they (reasonably) were not very enthusiastic about giving a definative answer since another 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. any help/suggestions/RTFMs welcome cheers, gerry -- gerry pratt - workstation support - university of keele email: cca13@uk.ac.keele.seq1 * tel: 0782 621111 x 3290
jonathan@cs.keele.ac.uk (Jonathan Knight) (06/07/90)
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.
yuf@sequent.UUCP (Kyle Grieser) (06/09/90)
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
robert@shangri-la.gatech.edu (Robert Viduya) (06/09/90)
>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
jonathan@cs.keele.ac.uk (Jonathan Knight) (06/11/90)
From article <36464@sequent.UUCP>, by yuf@sequent.UUCP (Kyle Grieser): > When NFS goes across the wire to the server > machine, it goes as "root" (/usr/ucb/{rlogin, rsh} are setuid "root"). Could be. However, I was the person who originally demonstrated the problem to Gerry and I have my .rhosts file world readable. At the time I had an intermittent problem with reading any files in my area which I thought might be linked to the problem, however I cannot re-create the problem now. What I saw was first a demand for my password (even though I had the correct entry in my .rhosts) and then this: % cat .rhosts cat: read error: permission denied % touch some_file_which_doesnt_exist % cat .rhosts normal listing.... This worked for any file in my area. I felt that this was possibly related seeing as if I couldn't read my .rhosts until I altered the directory then I presumed that rlogind couldn't either. Today I tried to re-create the problem and couldn't. I have a .rhosts which is world readable, as an experiment I altered it back to the 600 permissions. I can log in without a password which is the correct result. I have a feeling that there is another condition that I don't know about which causes the problem to appear. -- ______ 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.
roy@prism.gatech.EDU (Roy Mongiovi) (06/13/90)
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