Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: rlogin over trusted hosts...
Message-ID: <14006@mimsy.UUCP>
Date: 15 Oct 88 15:34:06 GMT
References: <3043@mipos3.intel.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 34

In article <3043@mipos3.intel.com> rpartha@cadev4.intel.com
(Rajan Parthasarathy) writes:
>I noticed a possible problem with the "rlogin" command.

It may be a problem for you; but it is *supposed* to work that way.

>Typically the accounts such as "sys", "news", etc. cannot be logged
>into since their /etc/passwd entries have a "*" in the password field.
>But, over a network it is possible to login as "sys" or "news" etc. ...
>
>    # su sys

*Here* is the problem.  hosts.equiv gives every account (except root)
on machine `remote' access to the account on machine `local' with the
same login name.  But root on `remote' has access to every account on
`remote'; so obviously hosts.equiv gives remote's root access to every
account (save root) on `local' as well.

>... The question remains as to what kind of implications this "feature"
>can have. Are there any potential problems that can be forseen??

If you use hosts.equiv as it is intended, none.

Okay (I hear you ask), how is it intended to be used?

hosts.equiv names those machines that you yourself administer or
otherwise trust completely.  It does *not* name machines that you have
even the least little bit of uncertainty about.  Hence the fact that
you can (on machine remote) su to root and then to sys and then rlogin
does not bother you at all, because you can (on machine local) su to
root and then to sys, which has the same effect anyway.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris