Re: dynamic pty allocation.

Greg Alexander (galexand@sietch.bloomington.in.us)
Sat, 21 Mar 1998 04:13:14 -0500 (EST)


On Sat, 21 Mar 1998, C. Scott Ananian wrote:

> > I got 2.1.90 right after posting my original message and knew that something
> > ptmx-like was the right answer.. However, "setting ownership" isn't
> > properly Unixy. It's even more improper than, say, kmod calling
> > /sbin/modprobe. :)
>
> Good thinking: I suggest you look at the unix98 semantics and the way
> we implemented this in glibc. You are right, permissions
> belong in usermode. However, *locking* needs to be done in the kernel
> for things to work right; this is what was done. This code has
> already been written and standardized.

It's been written and standardized wrongly, I say. :) It needs to be
dynamic and smooth and perfect and pretty and feel right and stuff.

> What Alan is referring to is this code in linux/drivers/char/pty.c:
>
> static struct tty_struct *pty_table[NR_PTYS];
> static struct termios *pty_termios[NR_PTYS];
> static struct termios *pty_termios_locked[NR_PTYS];
> static struct tty_struct *ttyp_table[NR_PTYS];
> static struct termios *ttyp_termios[NR_PTYS];
> static struct termios *ttyp_termios_locked[NR_PTYS];
> static struct pty_struct pty_state[NR_PTYS];
>
> where NR_PTYS is typically 256.
>
> "Allocate dynamically" means replacing this fixed-length array with a
> more flexible scheme that wouldn't constrain us to 256 pty pairs.
> Once this is done, we run into the dev_t problem, namely that there is
> only a minor number allocation for 256 different ptys.
> /devfs solves this problem.

What Alan /actually/ suggested was that I make a syscall that acts similarly
to pipe() except for ttys. I liked that idea a lot because, IMHO, ttys are
/dumb/. Having everything a file is pointless if all files are not created
equal -- if you can't ioctl() pipes but you can ioctl() some files, you've
got a problem. But since I can't escape that, Alan's idea sounded good.
What I came up with and have implemented and solves all the security
problems CLEANLY (I'm not sure how glibc implements it, I'll look), simply,
and uniformly, doesn't clutter /dev, doesn't have dev_t limits, is fully
dynamic, and is much less dumb than having any sort of static structure
(/dev/pty* is assumed to be static no matter how many fd's, otherwise we're
assuming rootness which is /bad/) for an inherently dynamic dataset.
'sides, I bothered to write this and I'll be damned if I'm gonna use
some halfway backwards compatable solution just because it's standard. We
both know this standard isn't entrenched enough to be worth much more than
each sysad setting up his own scheme, which is what it has amounted to up
until now.

Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
>One basic notion underlying Usenet is that it is a cooperative.
Having been on USENET for going on ten years, I disagree with this.
The basic notion underlying USENET is the flame.
-- Chuq Von Rospach, chuq@Apple.COM

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu