pseudo-tty permissions problems (proposal)
Greg Alexander (galexand@sietch.bloomington.in.us)
Wed, 4 Jun 1997 04:37:40 -0500 (EST)
I consider pseudo-tty's to be a huge weakness of Unices, but I don't
know a good solution that doesn't include things that won't happen (most
notably, ioctl and termios over a pipe and potentially eliminating all
kernel involvement in pid <-> tty association).
Anyways, the biggest problem is that your slave-ptty's need to be
chown'd to the user who opened the master-ptty for security reasons. If
they're not, you get problems (it may be in a bad state, owned by another
user...if it's mode 666, you have tty hijacking). It's been solved
(WRONGLY!) by just giving the program that opens the ptty suid root (i.e.
xterm, rxvt, screen) or just accepting the above problems. Neither of these
is acceptable. I've so far solved this with a userland daemon
(ftp://sunsite.unc.edu/pub/Linux/Incoming/pttyd-0.9.tgz for now) that
accepts requests (over a socket) for rights to a slave tty (and checks if
the pid that requested this has the master tty open first to prevent
hijacking). I was showing this to some friends and they promptly said that
it really should be solved in the kernel.
Now I don't really know where it should be solved, as I think ptty's
are broken anyways. :) I'd like to know if anyone else thinks this should
be in the kernel, or if it should all be user-mode daemons like it is now.
If it's in the kernel, it would probably be implemented so that when a
process tries to open a slave-ptty their request will only be allowed if
the same uid owns the associated master-ptty.
Greg Alexander
http://www.cia-g.com/~sietch/
----
"I read about monkeys in the encyclopedia as soon as I got home from the
funeral and I wonder if this one throws turds and masturbates all the time
like those monkeys saw it the zoo in San Francisco or if witness monkeys are
more like people."
-- a character in Orson Scott Card and Kathryn H. Kidd's novel,
Lovelock.