🚀 go-pugleaf

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