brent@uunet.uu.net (Brent Chapman) (03/04/89)
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-6400guy@uunet.uu.net (Guy Harris) (03/24/89)
> '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"). Exactly. Those changes come from 4.3BSD. >Unfortunately, 'login' doesn't check this, it just assumes it to be >true. Not true. I just tried it on a 4.0 system, and it not only changed the owner of the pseudo-tty on which I telnetted in to me, it changed the group owner to group "tty". I checked the 4.3BSD code (from which the SunOS code is derived), and it does, indeed, attempt to change the group ownership of the tty to group "tty". Now, if the "getgrnam" in "login" (or, at least, the 4.3BSD version of same) that tries to look up group "tty" in order to find its group ID fails, it changes the group owner to the user's "default group" (the one in the password file) instead; perhaps "/etc/group", or the YP map for it, is missing a "tty" entry or is inaccessible? >The problem is, 'in.telnetd'...sets the group ownership of the pty it >was using to GID 0 apparently in a misguided attempt to "clean >up" after itself. If you think it's misguided, I suggest you talk to the 4.xBSD folks at Berkeley about it, since not only does the 4.3BSD version do this, the 4.3-tahoe version does as well, so as of when they did the 4.3-tahoe version, they didn't consider it misguided. Asking Sun to change it may result in it being changed in SunOS, but not in 4.xBSD nor in systems other than SunOS that have gotten "telnetd" (or "rlogind" for that matter - it does the same thing) from 4.xBSD....