ptys and Unix98

C. Scott Ananian (cananian@lcs.mit.edu)
Thu, 15 Jan 1998 04:42:25 -0500 (EST)


There has been a request to add an automatic permissions change to the
pty code. This would be similar to the functionality required by the
Unix98 function grantpt():

--------- Unix98 standard ---------
int grantpt(int fildes);

DESCRIPTION

The grantpt() function changes the mode and ownership of the slave
pseudo-terminal device associated with its master pseudo-terminal
counter part. The fildes argument is a file descriptor that refers
to a master pseudo-terminal device. The user ID of the slave is
set to the real UID of the calling process and the group ID is set
to an unspecified group ID. The permission mode of the slave
pseudo-terminal is set to readable and writable by the owner, and
writable by the group.

The behaviour of the grantpt() function is unspecified if the
application has installed a signal handler to catch SIGCHLD
signals
------------ end standard --------

Note that the standard explicitly allows an out: we can fork and
execv a process to implement grantpt(). But that seems ugly.

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].

Do people want to see this functionality in the kernel?
--Scott

[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.]
@ @
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-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