🚀 go-pugleaf

Submitted-by: sef@kithrup.COM (Sean Eric Fagan)

In article <15827@cs.utexas.edu> nix%valis.asd.sgi.com@SGI.COM (Insufficient Dada) writes:
>This behavior breaks
>the subshell handling of GNU Emacs, and apparently interferes with the
>operation of the XView terminal emulator as well.  

First of all, emacs needs to do a setsid() in the sub-process; this makes
the pty it's controlling terminal (at least, this is how it works under
SCO's unix).

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

I got this idea from a discussion with people at Berkeley.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 31

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

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

Submitted-by: sef@kithrup.COM (Sean Eric Fagan)

In article <16068@cs.utexas.edu> thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen) writes:
>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?)

Because that won't support existing practice.

Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob."  It is
defined to send a SIGINT to the process group.  Not a control-c, or DEL, or
whatever you have your interrupt character defined as.  Note that emacs
terminates the shell by sending it (I believe) a SIGTERM.  What keyboard
sequence generates that signal?

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

Volume-Number: Volume 22, Number 37

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

sef@kithrup.COM (Sean Eric Fagan) writes:
>thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen) writes:
>>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?)

>Because that won't support existing practice.

>Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob."  It is
>defined to send a SIGINT to the process group.  Not a control-c, or DEL, or
>whatever you have your interrupt character defined as.  Note that emacs
>terminates the shell by sending it (I believe) a SIGTERM.  What keyboard
>sequence generates that signal?
	
That is exactly the point: Keyboard generated signals are more
powerful than the kill system call, because uids are not checked.
Under ``existing practice'' you can send SIGINT, SIGQUIT or SIGTSTP to
all processes in the process group of a pseudo-tty, _even_if_ some of
them are set-uid to someone else.

But a set-uid root program can assume that a SIGTERM comes from a
super-user. If a new ioctl allows any signal to be sent without
checking uids, the rules have been changed (not nice). If it checks
uids for all signals, it's less powerful than keyboard signals, and
why bother to learn about it?

By the way, I will hazard a guess: Most, if not all, of the UNIX
variants where the existing practice of Emacs doesn't work will have
SYSV termios ioctls. So instead of putting in ifdefs for two or three
subtly incompatible new TIOCSENDSIGs, we might as well put in the four
lines to get a termios structure and stuff the appropriate character
down the master pty.

--
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 45