Xref: utzoo comp.unix.admin:877 alt.sys.sun:2554
Path: utzoo!utgpu!cs.utexas.edu!samsung!usc!rutgers!njin!princeton!tan.Princeton.EDU
From: pfalstad@tan.Princeton.EDU (Paul Falstad)
Newsgroups: comp.unix.admin,alt.sys.sun
Subject: SunOS 4.1.1 in.telnetd problems
Message-ID: <5676@idunno.Princeton.EDU>
Date: 24 Jan 91 21:56:53 GMT
Sender: news@idunno.Princeton.EDU
Followup-To: comp.unix.admin
Organization: The E. Henry Thripshaw Fan Club
Lines: 80

We're having tty problems at our site (SunOS 4.1.1).  Sometimes people
will login, see the /etc/motd, and then get logged out again.  Doing an
ofiles on their tty shows that someone has a process running on that tty;
sometimes the process is actually a login shell that didn't die for some
reason.  Having the sysadmin kill the processes or doing a "cat </dev/pty?? &"
(which prevents in.telnetd from using that pty) solves the temporary
problem, but this should not be necessary.

Also, people will sometimes run background processes and forget to
redirect their output, causing people to have garbage dumped to their
screen.  There is also a security risk involved; if you login on ttyp0
and ttyp1, and then on the p1 terminal type "cat </dev/ttyp0", then
logout on p0 and wait for someone else to login there, the stuff they
type appears on your screen.

The question is, shouldn't vhangup(2) solve these problems?  According
to the SunOS man page, vhangup causes future access to the terminal to
yield an EBADF, and sends a SIGHUP to the process group of the control
terminal (though this doesn't help much with csh background jobs).  This
doesn't happen.  Look at this C program:

#include <signal.h>
extern int errno;
main(int argc,char **argv)
{
char c;
int a;
signal(SIGHUP,SIG_IGN);
sleep(atoi(argv[1]));
a = read(0,&c,1);
printf("%d %d\n",a,errno);
}

Compile this and run it like:

./a.out 10 >/tmp/foo &

and then log out.  10 seconds later, you can read the output in /tmp/foo.
The output I get on a SunOS system is "0 4".  This is wrong.  BSD4.3
gives the correct output "-1 9" (-1 means the read failed, 9 is EBADF).

I read the vhangup man page again, and noticed this line:

   To affect this, vhangup() searches the system tables for
      ^ (should be effect :-)

   references to the control terminal of the invoking process,
                 ^^^^^^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^^^
   revoking access permissions on each instance of the
   terminal that it finds.

So, I did a ps -aux listing, and grepped for telnetd.  BSD4.3 says:

root      9672  0.0  3.6   64  256 p4 S    16:09   0:03 in.telnetd
root      5071  0.0  0.9   64   64 p1 S    20:14   0:19 in.telnetd
root      9130  0.0  0.0   64    0 p2 IW   13:54   0:06 in.telnetd
                                   ^^

SunOS, however, says:


root     28321  0.0  0.0   48   64 ?  S    16:24   0:00 in.telnetd
root      1184  0.0  0.0   48    0 ?  IW   Jan 23  0:00 in.telnetd
root     28158  0.0  0.0   48   64 ?  S    16:22   0:00 in.telnetd
root     16423  0.0  0.0   48    0 ?  IW   15:22   0:00 in.telnetd
root     24344  0.0  0.0   48   64 ?  S    16:01   0:02 in.telnetd
root     22523  0.0  0.0   48   64 ?  I    15:52   0:01 in.telnetd
                                   ^^

Sun telnetd's have no controlling terminal, so the vhangup() has no
effect.  Why did Sun make this change to telnetd?  Did they replace
vhangup() with some other mechanism to keep ttys secure?  If so, why
doesn't it work?  If not, this will be the second bug I've found in
SunOS this year.  This is causing the sysadmins at our site (as well as
the students) a lot of grief.  Any help appreciated.  Thanks.

--
Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD
"And she's always on about men following her.  I don't know what she
thinks they're going to do to her.  Vomit on her, Basil, says."-Flowery Twats