> 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