Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!cs.tamu.edu
From: haustin@cs.tamu.edu (Harold E Austin Jr.)
Newsgroups: comp.sys.next
Subject: shells and 2.0 rlogind
Message-ID: <14378@helios.TAMU.EDU>
Date: 9 Apr 91 03:18:24 GMT
Sender: usenet@helios.TAMU.EDU
Organization: Computer Science Department, Texas A&M University
Lines: 33

Here's an interesting problem that I hope the NeXTperts on the net can solve...
(I apologize if this has been answered many times before.  If that's the case,
please e-mail responses to me and send the flames to /dev/null. :)

The rlogind daemon in version 2.0 has an undesirable "security feature" :).
It seems that no one with a default shell other than /bin/sh or /bin/csh can
rlogin to a machine running 2.0.  

At our site, there is a small group of users who have "/bin/next_csh" as their
default shell.  On our NeXTs, this is simply a link to /bin/csh; but its 
absence on the Sparcs keeps "NeXT-only" users in the NeXT Lab.  (next_csh is
not listed in /etc/shells on the YP server, so users cannot use ypchsh to 
change their shells to something that DOES exist on the Sparcs.)

With this shell, users can login at the console, and rsh and telnet to a 2.0 
machine.  However, if such a user attempts to _rlogin_ to a 2.0 NeXT, the
shell hangs before sourcing .cshrc and .login (and runs up to 99% CPU!).  
I discovered today that the problem also exists for users with /bin/tcsh as
their default shell.

Yes, both "/bin/next_csh" and "/bin/tcsh" are listed in /etc/shells on the
NeXTs.  (Without this, loginwindow refuses to allow console logins.)

Any ideas?  Thanks in advance.

Harold Austin
_______________________________________________________________________________
 o |									   | o
 o |					Harold E. Austin. Jr.		   | o
 o |									   | o
 o |					Department of Computer Science	   | o
 o |					Texas A&M University		   | o
 o |					haustin@cs.tamu.edu		   | o