Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: capmkt!brent@uunet.uu.net (Brent Chapman)
Newsgroups: comp.sys.sun
Subject: 4.0 in.telnetd is improperly restoring tty group ownership on exit
Message-ID: <8902201841.AA09835@mycroft.capmkt.com>
Date: 4 Mar 89 05:21:55 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 49
Approved: Sun-Spots@rice.edu
Original-Date: Mon, 20 Feb 89 10:41:45 PST
X-Sun-Spots-Digest: Volume 7, Issue 180, message 6 of 12

After wondering why 'talk' and 'write' would sometimes fail even though a
user's tty was apparently writable, I noticed that, under 4.0:

    'talk', 'write', 'wall', and other programs which expect to write
	on a user's tty are now set-GID to group "tty".
    'login' sets the mode of a user's tty to be group-writable but not
        world-writable when the user logs in.
    'in.telnetd' sets the group-ownership of the pty it's been using to
	GID 0 ("wheel") on exit.

The first two above are apparently to keep random users from writing to
your screen except through "approved" channels (which must now be set-GID
to group "tty").  This only works if the user's tty is in fact owned by
group "tty".  Unfortunately, 'login' doesn't check this, it just assumes
it to be true.  The problem is, 'in.telnetd', when an incoming connection
is closed, sets the group ownership of the pty it was using to GID 0
(which happens to be "wheel"), apparently in a misguided attempt to "clean
up" after itself.  This means that any future unfortunate souls to end up
with that pty won't be reachable by 'talk', 'write', or 'wall' (unless the
calling party is root), until someone 'chgrp's the pty back to group
"tty". 

Anyway, the way I see it, there are two fixes that should be made:
    1)	in.telnetd should not set group-ownership of the pty to 0 on exit;
	if anything, it should restore the ownership that the pty had when
	in.telnetd started.
    2)	login should make sure the tty or pty is group "tty" at the same time
	it changes the owner to the user logging in.

The workaround is to put something in your crontab that 'chgrp's all pty's
to group "tty" every so often.

I'm not running 4.0 at our site (these problems were discovered on some
4.0 machines at UC Berkeley that I have access to), so I haven't reported
this to hotline@sun.com yet; I'd appreciate it if someone (preferrably
lots of someones) would verify these problems on their own system (check
that the group of all pty's (/dev/tty[pqr]*) is "tty", then telnet to
yourself, log in, see what tty/pty you're on, log out, wait for the telnet
connection to close, and check the group ownership of the tty/pty you came
in on; it's probably not "tty" any more), and then report them to Sun.
That way, maybe it'll be fixed by the time I finally bite the bullet and
"upgrade" us to 4.0.x...  :-)

-Brent
--
Brent Chapman					Capital Market Technology, Inc.
Computer Operations Manager			1995 University Ave., Suite 390
brent@capmkt.com				Berkeley, CA  94704
{cogsci,lll-tis,uunet}!capmkt!brent		Phone:  415/540-6400