> 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