Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-ID: <16068@cs.utexas.edu>
Date: 21 Dec 90 20:25:01 GMT
References: <15827@cs.utexas.edu> <15975@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Institute of Computer Science, U of Copenhagen
Lines: 32
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

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

rml@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@diku.dk

Volume-Number: Volume 22, Number 36