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-6400
guy@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....