Messages in this thread | | | Date | Sat, 21 Mar 1998 05:33:38 -0500 (EST) | From | "C. Scott Ananian" <> | Subject | Re: dynamic pty allocation. |
| |
On Sat, 21 Mar 1998, Greg Alexander wrote:
> The way glibc has implemented it reminds me a lot of: > > > I did make a userspace daemon that would chown slave tty's if the caller > > > opened the master. :)
This also happens to be how Solaris implements it. After much consideration (we spend quite some time) this seems to be, all-around, the best approach.
> I want to know how you think these two problems (security and dynamicity) > can be solved without removing the devices from the filesystem.
You're confusing several different issues which should be dealt with individually.
> Calling a > suid program is silly from a security standpoint (though not useless, no > more useless than my pty daemon, which was quite useful).
Not necessarily. Is kerneld and kmod silly? A suid helper seems to be the most simple and natural way to do it. You should talk to the glibc and the Unix98 people if you've better ideas. *Certainly* specific user and group ids and security *policy* do not belong in the kernel, so we are not talking about a linux-kernel issue here.
> I don't see any > way to create device fd's cleanly and dynamically on disk.
Right. This is why /proc and its virtual filesystems are attractive. This is issue #1, which is addressed by /devfs and similar solutions. There was discussion about this a while ago on linux-kernel. This is *not* a pty issue. /devfs has the advantage of being implemented. Again, to take a cue from our commercial brethern, Solaris has a devfs-style system: Scott on w20-575-39[~]% ls -l /dev/pts/0 lrwxrwxrwx 1 root root 28 Aug 7 1996 /dev/pts/0 -> ../../devices/pseudo/pts@0:0
This is not the "dynamic pty" problem. This is the on-disk-device-files problem.
> alternatives. I don't, however, see a good reason that we have to have > a file for these things at all. Do we have to have a file for each > thingy opened with pipe()? No, of course not, and these are no more > substantial than pipes.
Look at the pipe() implementation in the kernel. We do in fact have a 'struct file' for each pipe. The 'file' doesn't live on disk, of course, but its abstract conceptualization is a useful kernel abstraction.
>>> 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.
But this is already implemented, and called /dev/ptmx. The (slightly different) way that ptmx implements it is what is required by the Unix98 standard. Standard ways of doing things are (almost) always best.
But *this* is not the "dynamic pty" problem, either. This is the pty-interface problem.
> <clip> > > 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. > > To make these dynamic, I have to do what I've done now minus the TIOCGPTFD > ioctl.
No, no, no! The dynamic-pty problem ensures that if I use *only 2* ptys, then *only 2* pty_table (&etc) entries are allocated in memory. When (and only when) I open the third, its memory is allocated.
If this is coded properly, then we can have as many ptys as we want. Even more than 256, although accessing pty #257 will have to await either 1) a 64-bit dev_t (linux 2.3.X?) or 2) solution to the on-disk-device-files problem (/devfs?). The solution choosen to the 257-ptys problem has nothing to do with the dynamic-pty problem.
I suggest you spend your kernel-hacking energy on the dynamic-pty problem, which *is* a real documented need. First off, Linus likes simple solutions to clearly defined problems better than hairy hacks to address vague issues (part of GGI/KGI's integration troubles have been the *scope* of the problems they are trying to address). Second, there is already application code which uses the Solaris/Unix98-style pty interface. There is no code outside your machine which uses /dev/dpty. The numbers suggest that this situation will persist. --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
| |