Messages in this thread | | | Date | Sat, 21 Mar 1998 03:27:11 -0500 (EST) | From | "C. Scott Ananian" <> | Subject | dynamic pty allocation. |
| |
On Fri, 20 Mar 1998
> The way /dev/ptmx is implemented, it does search through all the ptys > internally. :)
Right. For 256 max possible devices, it doesn't yet make sense to do it any other way.
> > Now, what we want is a /dev/ptmx which normal users can open as > > well. This could be accomplished by setting ownership when opening > > /dev/ptmx if the calling process is not root. This would be a simple > > extension of the current semantics. For programs that used /dev/ptmx > > already (not many on linux I know..) you can start running it as > > non-root. No code needs to be changed. > > 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.
> Most of the problem is that converting kdev_t to inode > is quite a bitch and I don't know how proper it is to assume that > /dev/tty[p-za-e]? are named standardly or to enforce such decisions that a > lot of sysads like to keep for themselves (i.e. what do we do with the > groups). I could just add another /proc variable, I guess...but I really > wanted to make this dynamic. FWIW, I did make a userspace daemon that would > chown slave tty's if the caller opened the master. :)
Ack. I'm dying here.
> So... A new device (/dev/dpty?) that, on open, appears similar to > /dev/ptmx...it'll allocate a new pty master (and it looks like the code is > setup such that we'd allocate the slave here too) and make the current file > point to that tty structure. Then the code would call ioctl(TIOCGSPTFD) (or > something)...Get Slave Pseudo-Terminal File Descriptor.
No, no, no, no, no!
> Therefore, /dev/ptmx code like: > master=open("/dev/ptmx",...); > ioctl(master,TIOCGPTN,&ptn); /* Get PT number */ > sprintf(s,"/dev/tty%s",ptn_to_string(ptn)); > slave=open(s,...); > would be replaced with: > master=open("/dev/dpty",...); > ioctl(master,TIOCGSPTFD,&slave);
Gag me with a spoon!
ptymx code looks like:
fd = open("/dev/ptmx", O_RDWR); grantpt(fd); unlockpt(fd); fd2=open(ptsname(fd), O_RDWR);
Read the Unix98 spec. Read the glibc sources. Read the ptymx test package.
> I can always go back and implement /proc and other interfaces later. > Do any kernels (of any unix flavor) allocate ptys dynamically yet?
Aaaaaaaaarrrrrrgh.
"/proc and other interfaces" is probably /devfs. This has *also* already been written.
"allocate ptys dynamically" is what Alan *asked* you to do, which is *completely different* from what these schemes you are proposing do! The security issue has *already been coded!*
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. --Scott @ @ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-= C. Scott Ananian: cananian@lcs.mit.edu / Declare the Truth boldly and Laboratory for Computer Science/Crypto / without hindrance. Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31 -.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -. PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |