disabling TIOCGPGRP on pty master sides

Lars Henrik Mathiesen thorinn at rimfaxe.diku.dk
Sat Dec 22 07:25:01 AEST 1990


Submitted-by: thorinn at rimfaxe.diku.dk (Lars Henrik Mathiesen)

rml at hpfcdc.fc.hp.com (Bob Lenk) writes:
>Again, pty master features are not covered by POSIX.  There are some
>tradeoffs between these two approaches.  Supplying the process group ID
>through the pty master means that if the process running controlling the
>master side is no privileged (typically root), it will be unable to
>send signals to processes that have changed user IDs (eg. su).  However,
>the ioctl to send a signal requires appropriate security checks in a
>production implementation.  There are questions as to what these need to
>be; I suggest that the process should be able to send any tty signals
>but no others, since any process/user on the slave slide accepted (at
>least implicitly) the possibility of receiving these when affiliating
>with a (pseudo) terminal.

We're discussing an ioctl, usable on a master pty to send terminal
signals to processes in the slave side's process group, right?

I'd very much hope that such an ioctl would include checks for the
termio settings of the slave side: A signal should only be allowed if
it would be possible to write a character on the master pty to achieve
the same result. (And then, why not do just that?)

Otherwise, a set-uid process that unsets the ISIG flag might be
subverted with unexpected signals by users running it under a pty.
(Personally, I'd block the signals as well, but I'm not everybody.)

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn at diku.dk

Volume-Number: Volume 22, Number 36



More information about the Comp.std.unix mailing list