> By author: "C. Scott Ananian" <cananian@lcs.mit.edu>
> > I propose an ioctl to toggle the permissions on a given (open) pty.
> > One mode would allow anyone permitted by the on-disk file permissions to
> > open the pty, the other would restrict access as specified by grantpt().
> > The default setting on pty open could be user-configurable. Unix98
> > requires an unlockpt() function call to explicitly unlock the pty before
> > open, so a 'lock permissions on open' configuration would work for all
> > glibc applications (once the support makes it into glibc, of course), and
> > provide extra security for old-style applications. [Unix98 semantics seem
> > to be that the state of a pty is uncertain until unlockpt() or grantpt()
> > is called, so either default would be compliant].
[...]
> > [Note that this is a completely separate issue/patch from my previous
> > work providing support for the /dev/ptmx device and ptsname(). Strictly
> > speaking, Unix98 compatibility requires ptsname support, but does not
> > require the permissions hack we are currently discussing -- as mentioned
> > above, grantpt() can be implemented via fork() and exec(), and unlockpt()
> > can be a no-op.]
> I'm concerned about separating this functionality because it opens up
> additional potential security holes. If you create the device nodes,
> set the ownership, and the modes, all at one time, you know what
> you're dealing with and if you do it from kernel space you can
> trivially guarantee that nothing else is getting in between.
>
> Hence my suggestion that opening /dev/ptmx should create the
> appropriate /dev/pts/* device node in place with the right owner and
> permssions. The grantpt() call would then be a noop, as far as I
> understand.
I think you misunderstood my suggestion. I was proposing that the ioctl
exist -- *but that default behavior was configurable*. So on your system
you can have opening the pty slave automagically set the permissions
properly, while if this breaks things for other people they could disable
this *in the kernel configuration*.
*BUT*
At this time I see no good reason for any of this functionality.
It is not necessary for Unix98 pty support, so I am not going to implement
it. Someone else can take up the banner, write a patch, and try to get it
accepted. I will concentrate on getting support for /dev/ptmx into glibc.
[Assuming that my first, minimal, version of the ptmx patch makes it into
the kernel. Haven't heard back from Linus yet.]
--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