haustin@cs.tamu.edu (Harold E Austin Jr.) (04/09/91)
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
cattelan@mermaid.micro.umn.edu (Russell Cattelan) (04/11/91)
haustin@cs.tamu.edu (Harold E Austin Jr.) writes: >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 this is a anoying like *BUG* in 2.0 To fix this replace /bin/login and /usr/etc/rlogind with the 1.0 binaries That is you have 1.0 copies around. This fixed the problem with tcsh and should fix the problem with your shell. -Russell Cattelan cattelan@cs.umn.edu
haustin@cs.tamu.edu (Harold E Austin Jr.) (04/11/91)
cattelan@mermaid.micro.umn.edu (Russell Cattelan) writes:
+ > 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 this is a anoying like *BUG* in 2.0
+ To fix this replace /bin/login and /usr/etc/rlogind with the 1.0 binaries
+ That is you have 1.0 copies around.
+
+ This fixed the problem with tcsh and should fix the problem with your shell.
+
+ -Russell Cattelan
+ cattelan@cs.umn.edu
Yep, it worked! And it also fixed another 2.0 rlogin problem: /.rhosts was
ignored when root tried to rlogin to a 2.0 machine. Always asked for a passwd.
By downgrading to 1.0 binaries for /bin/login and /usr/etc/rlogind, we killed
two bugs with one stone. :)
Thanks,
Harold Austin
(haustin@cs.tamu.edu)eps@toaster.SFSU.EDU (Eric P. Scott) (04/11/91)
First of all, /usr/etc/rlogind doesn't know ANYTHING about shells.
/bin/login does has a check for shell == /bin/csh, but all it
does is enable NTTYDISC (and this code is removed in 4.3-reno,
since it's really unnecessary). There isn't anything here that
would prevent any particular shell from functioning.
So what's going on? Well, the culprit is this piece of code in
[ancient version of] rlogind right before it forks to exec
/bin/login:
#ifdef DEBUG
{
int tt = open("/dev/tty", O_RDWR);
if (tt > 0) {
(void)ioctl(tt, TIOCNOTTY, 0);
(void)close(tt);
}
}
#endif
(the above is not present in 4.3-reno)
Apparently, NeXT compiled rlogind with DEBUG defined. Why? I
don't know why. But this caused /bin/login to be started with no
control terminal. csh doesn't like this. csh REALLY doesn't
like this.
To test this theory, I made a copy of rlogind with the "/dev/tty"
(offset 8818 decimal) scribbled over, and changed /etc/inetd.conf
to run that instead. Not surprisingly, things seemed to work
just fine after that.
Of course, we'd all be happier if rlogin simply went away...
BTW, going back to 1.0 versions is not such a good idea in this
case.
-=EPS=-kloppen@gmdzi.gmd.de (Jelske Kloppenburg) (04/11/91)
haustin@cs.tamu.edu (Harold E Austin Jr.) writes: >Here's an interesting problem ... >It seems that no one with a default shell other than /bin/sh or /bin/csh can >rlogin to a machine running 2.0. >... >Any ideas? Thanks in advance. If I rlogin to my NeXT 2.0 with default shell /bin/ksh, I succeed, but if I then make ps, I have no process. If I make ps -x, I find my process with tty ?. The problem seeems to be, that sh and csh ar waiting for the information, what the controlling terminal is. (Bad English? excuse me!) Jelske Kloppenburg, kloppen@gmdzi.gmd.de, (++49 2241) 14-2433 German National Research Center for Computer Science (GMD)