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