nix%valis.asd.sgi.com@SGI.COM (Insufficient Dada) (12/14/90)
Submitted-by: nix%valis.asd.sgi.com@SGI.COM (Insufficient Dada) POSIX apparently specifies that the TIOCGPGRP ioctl is disabled if called on a terminal other than the controlling terminal of the calling process, apparently for security reasons. This behavior breaks the subshell handling of GNU Emacs, and apparently interferes with the operation of the XView terminal emulator as well. GNU Emacs uses ptys to communicate with shell subprocesses, and attempts to send signals to the foreground process in a subshell by finding the process group associated with the (master side of the) pty. 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? If not, could someone elaborate on the security problems with allowing a process to find the pgrp of an arbitrary tty? How about allowing a process to find the pgrp of the slave side of a pty when it owns the master side? Nick Nick Thompson nix@sgi.com ...!uunet!sgi!nix Volume-Number: Volume 22, Number 30
sef@kithrup.COM (Sean Eric Fagan) (12/15/90)
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
rml@hpfcdc.fc.hp.com (Bob Lenk) (12/18/90)
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
thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen) (12/22/90)
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
sef@kithrup.COM (Sean Eric Fagan) (12/22/90)
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
barmar@think.uucp (Barry Margolin) (12/24/90)
Submitted-by: barmar@think.uucp (Barry Margolin) In article <16118@cs.utexas.edu> sef@kithrup.COM (Sean Eric Fagan) writes: >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?) >Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob." It is ^^^^^^ C-cC-C >defined to send a SIGINT to the process group. Not a control-c, or DEL, or >whatever you have your interrupt character defined as. One problem I've run into with the current implementation is that it has trouble when I run a setuid program in the shell buffer. The Emacs process can't send signals to the setuid process. I ended up redefining C-cC-c and C-cC-z to just stuff ^C and ^Z into the pty. However, your idea of an ioctl to send a signal to the other side of a pty (I assume that's what this is about, I missed the beginning of the discussion) seems like it would be just right. Normal terminal users sometimes get stuck because a program disables control characters and then a bug sends it into an infinite loop. The problem is the multiplexing of the keyboard for input to the program and process control. On the other hand, when a program is being run through a pty there is no need to disable signals just because the signal *characters* are disabled. Ioctls provide the needed out-of-band mechanism for process control that is not available on a real terminal. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar Volume-Number: Volume 22, Number 38
thorinn@diku.dk (Lars Henrik Mathiesen) (12/29/90)
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
sef@kithrup.COM (Sean Eric Fagan) (12/29/90)
Submitted-by: sef@kithrup.COM (Sean Eric Fagan) In article <16290@cs.utexas.edu> thorinn@diku.dk (Lars Henrik Mathiesen) writes: >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. Yep. All POSIX systems. >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. (shell) <stuff> kithrup 341> stty intr ^Y kithrup 342> <C-cC-c>^?<C-cC-c>^?<C-cC-c>^?<C-cC-c>^? Gosh. It doesn't seem to be sending the control-y to the slave side of the pty! And, gosh, if it tries to do a TCGETAW, it just hangs! (Actually, I think it gets a SIGTTIN.) Some of this is SCO specific. But without rewriting the pty driver, *any* POSIX system with ptys is going to have the same problem (since sco's pty drivers aren't that different from berkeley's). According to email I exchanged with someone at CSRG, 4.4 will support the old method, but as an obsolescent feature. If the text is so ambiguous that it is implemented differently on every system, that means that you will need more ifdef's than with just the TIOCSIG ioctl. -- 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 46