Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!fitz
From: fitz@mml0.meche.rpi.edu (Brian Fitzgerald)
Newsgroups: comp.unix.questions
Subject: Re: Why does rsh give "Permission denied"?
Message-ID: <PM4-BF?@rpi.edu>
Date: 1 Mar 91 06:05:49 GMT
References: <1991Feb27.184617.106@athena.mit.edu>
Distribution: na
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 79
Nntp-Posting-Host: mml0.meche.rpi.edu

Jonathan I. Kamens writes:
>In article <C82-GC@rpi.edu>, fitz@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
>|> The directory path to $HOME should be executable by "others" and the
>|> .rhosts file should be readable by "others".  Adding or removing "user"
>|> or "group" permission bits, or the write or execute "others" bits to
>|> .rhosts does not alter this.

>  Oh, really?  I just created a .rhosts file mode 644, and tried to log in
>remotely without a password, and it didn't work.  I then changed it to mode
>600, and it did work.

Interesting!  Although I haven't used any rsh implementations which
deny access if certain bits are added, but I just received e-mail from
someone who observed this behavior after upgrading to SunOS 4.1.

>  The only time .rhosts has to be readable by others is on a system where home
>directories are remote filesystems (NFS, AFS, whatever) and root isn't
>trusted.  And, in that case, the BSD software has to be modified so that it no
>longer requires that group and world read permissions be unset from .rhosts. 
>It *does* check in standard 4.3BSD, and the reason for it is that if someone
>else can read your .rhosts, they can figure out what hosts and users they need
>to impersonate in order to log into your account without a password.
>
>  Same with the directory path being executable by others.  That is only
>necessary if any portion of the path is on a remote filesystem and root isn't
>trusted.

>|> The above is true of the Suns and aix machines I have seen.

I was mistaken.  The .rhosts mode must be at least 004 on aix and at
least 400 on the Suns, and adding bits doesn't change anything on the
machines I have seen.  Sorry.

>  Well, then, the machines you have seen have been modified to allow
>world-readable permissions on the .rhosts file.  This is not the "default"
>behavior of the BSD networking software, although it is becoming more common
>as more sites use remote filesystems for home directories.

Ok.  By the way, here's the source code for part of ruserok() from
bsd-sources on uunet, which I believe is the function that the "r"
commands call to decide whether to allow access to the remote user.  It
would appear that this is yet another version, which denies access on
the basis of writability by group or others, but not readability.  I
just bring this up to point out that there is a lot of variation out
there, which I didn't realize before I made my initial posting.

If IBM and Sun have hacked their implementations of this function, then
perhaps that is the reason for the differences.

For the last word on this topic, I defer to Jonathan Kamens.

Brian Fitzgerald

 * Copyright (c) 1983 Regents of the University of California.
 * All rights reserved.
...
        if (first == 1 && (_check_rhosts_file || superuser)) {
                struct stat sbuf;
                struct passwd *pwd;
                char pbuf[MAXPATHLEN];

                first = 0;
                if ((pwd = getpwnam(luser)) == NULL)
                        return(-1);
                (void)strcpy(pbuf, pwd->pw_dir);
                (void)strcat(pbuf, "/.rhosts");
                if ((hostf = fopen(pbuf, "r")) == NULL)
                        return(-1);
                /*
                 * if owned by someone other than user or root or if
                 * writeable by anyone but the owner, quit
                 */
                if (fstat(fileno(hostf), &sbuf) ||
                    sbuf.st_uid && sbuf.st_uid != pwd->pw_uid ||
                    sbuf.st_mode&022) {
                        fclose(hostf);
                        return(-1);
                }
                goto again;