Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: rml@hpfcdc.fc.hp.com (Bob Lenk)
Newsgroups: comp.std.unix
Subject: Re: disabling TIOCGPGRP on pty master sides
Message-ID: <15975@cs.utexas.edu>
Date: 17 Dec 90 20:37:52 GMT
References: <15827@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Lines: 52
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: rml@hpfcdc.fc.hp.com (Bob Lenk)

In article <15827@cs.utexas.edu> nix%valis.asd.sgi.com@SGI.COM (Insufficient Dada) writes:

> With TIOCGPGRP disabled, there seems not to be any way to send signals
> to a process running in an inferior shell other than figuring out the
> appropriate control character to send through termio to cause the
> signal to be sent.
> 
> Does POSIX have an alternate mechanism for this?

No.

>                                                   If not, could
> someone elaborate on the security problems with allowing a process to
> find the pgrp of an arbitrary tty?

I have not identified one after asking various people involved in
writing that portion of the standard.

>                                     How about allowing a process to
> find the pgrp of the slave side of a pty when it owns the master side?

There is nothing in any POSIX standard that specifies the master side
of a pty.  Thus such a feature would have no problems with respect to
the standard.

In article  <15891@cs.utexas.edu> sef@kithrup.COM (Sean Eric Fagan) writes:

> Second of all, because of the problem with tcgetpgrp() on another process'
> pty, I added (for my own use) a new ioctl to the pty driver, called TIOCSIG
> (as in, ioctl(fd, TIOCSIG, signo)), which sends an arbitray signal to the
> process group on fd.  (Since I did it only for emacs, I didn't put in any
> checks for security, although I plan on doing so eventually.)

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.

		Bob Lenk
		rml@fc.hp.com
		{uunet,hplabs}!fc.hp.com!rml

Volume-Number: Volume 22, Number 32