Hello,
> On Mon, 9 Oct 1995 10:51:07 +0100 (MET)
> 	cracauer@wavehh.hanse.de (Martin Cracauer) writes:
> > When /dev/ttyp? is not secure in /etc/ttys, I noticed that a .rhosts
> > for root refuses rlogin to the system, but allowes `rsh <command>`
> > with full su rights.
> It's normal behavior, because the command executed by rsh(1) doesn't
> have controlling tty like ttyp*.

I don't doubt it is normal, just want it to be changed.
 
> > That makes no sense. Should it be changed to refuse rsh as well when
> > ttyp* is not secure?
> How do you handling it, if ttyp0 is secure and ttyp1 is unsecure?

I can't imagine why anyone should handle  ttyp*'s different.

My point is, when the admin chooses not to allow root logins on
network terminals, he probably wants command lines sent by rsh,
blocked, too. 

A `rsh` command can change /etc/ttys and allows rlogin from that
moment on, so my points stays that handling rsh and rlogin different
makes no sense.

Seen the other way round, having a .rhosts as root mean "I know what I
do, regardless of secure-settings in /etc/ttys" and should allow login
via rlogin as well (may be useful to open logins from specific hosts,
but not from others).

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>  
(private address)
Tel.: +49 40 / 522 18 29
Fax.: +49 40 / 522 85 36