[buildd-tools-devel] Bug#566333: Bug#566333: need to ignore SIGTTOU ?

[Roger Leigh]

On Fri, Jan 22, 2010 at 03:18:08PM -0800, Kees Cook wrote:
> I seem to have run into a weird glitch when using the "command-prefix"
> option of schroot.  Namely, schroot is backgrounded by my shell on exit
> because it receives SIGTTOU when attempting to reset the termios on
> CTTY_FILENO:

Hmm, quite interesting!

Normally, we do this to restore the termios state if a program
running in the chroot messed up the state.  It's only done if
running a login shell (where it won't be backgrounded since it's
interactive) so we never receive SIGTTOU in this case: it's just
not possible since we are always the active process on the controlling
TTY.

> This happens for me because I've been playing with the CLONE_NEW* flags,
> and it seems that CLONE_NEWPID seems to trigger the tty layer into sending
> SIGTTOU when it attempts to reset the termios.

My understanding of SIGTTOU is that it's sent when a backgrounded
process attempts to write to the controlling TTY.  Normal processes
shouldn't handle it (or SIGTTIN) because the shell job control takes
care of everything.  If we ignore it, we might corrupt the output of
the current foreground process.

I think in consequence, the question to ask is: are we backgrounded
as a side-effect of CLONE_NEWPID?  If so, is this avoidable?

From my little understanding of CLONE_NEWPID, we probably automatically
become a session leader, in which case we must take responsibility for
job control and this has implications for terminal I/O and SIGTT*.
However, I don't know enough about it to make any definitive
conclusions; I suspect clarification from the kernel people may be
required.

> I can, for some reason, trigger this without anything very heavy-weight by
> calling "bash -i" from a simple wrapper, but that just illustrates the
> problem -- I'm not sure why it's happening under schroot only with
> CLONE_NEWPID.

I'll look into your examples when I next have some free time.
For the time being, I would be interested to know if the
problem exists when run under different shells such as
zsh or tcsh, just to make sure it's not bash-specific.

I don't think this is as a result of any incorrectness in schroot's
termios handling, but it's handling of termios may well be making
assumptions that no longer hold when using CLONE_NEWPID.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100123/aa5d5e53/attachment.pgp>