Messages in this thread | | | Subject | Re: dynamic pty allocation. | From | (Eric W. Biederman) | Date | 21 Mar 1998 12:12:50 -0600 |
| |
>>>>> "GA" == Greg Alexander <galexand@sietch.bloomington.in.us> writes:
GA> 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.
GA> It's been written and standardized wrongly, I say. :) It needs to be GA> dynamic and smooth and perfect and pretty and feel right and stuff.
But people disagree with you so you haven't yet achieved perfection :)
>> 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.
GA> What Alan /actually/ suggested was that I make a syscall that acts similarly GA> to pipe() except for ttys. I liked that idea a lot because, IMHO, ttys are GA> /dumb/.
How about instead of using pipe as a model use socket. Then the name problem can be solved by 'bind'ing your pty socket onto the filesystem. I suspect with sockets an extension could be made to allow the ioctl problem as ioctl being delivered as OOB data.
And since binding is a usermode issue it does all that is needed (kernel side) to solve the security problem. Which uid and gid etc to use is a usermode question. Keep it there.
GA> 'sides, I bothered to write this and I'll be damned if I'm gonna use GA> some halfway backwards compatable solution just because it's standard. We GA> both know this standard isn't entrenched enough to be worth much more than GA> each sysad setting up his own scheme, which is what it has amounted to up GA> until now.
It should be possible for code that uses the convetions from the standard to work.
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |