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

[Kees Cook]

Hi Roger,

On Sat, Jan 23, 2010 at 01:39:23PM +0000, Roger Leigh wrote:
> Hmm, quite interesting!

Yeah, it's a weird one alright.  :)

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

Yeah, I went and read the kernel code for when it sends SIGTTOU; I am not
very much more enlightened.  ;)

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

What I wanted to understand was what defines a process as "backgrounded",
since I think of this as a shell experience state, not a characteristic of
a process like pid, euid, etc.

The kernel handles this in drivers/char/tty_io.c tty_check_change().  I'm
eyeing this check:

        if (task_pgrp(current) == tty->pgrp)
                goto out_unlock;

i.e. if the process group is the same, don't send SIGTTOU.

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

What boggles my mind is that even if I SIG_IGN SIGTTOU in the process that
spawns the CLONE_NEWPID, it is still delivered to its parent (schroot).

> 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 played with this briefly.  In my tool, if I call setsid() before the
clone, the child base will fail with:
bash: cannot set terminal process group (-1): Inappropriate ioctl for device

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

Yeah, I'm going to go dig into this and try to find out exactly what bash
is up to.  I think you're right: it's related to process groups, session
leaders, and the controlling terminal.

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

Yeah, I'm starting to think that this is entirely my fault in using
CLONE_NEWPID and not correctly handling the session, which is probably
what I was triggering in "minimal.c" too -- that code doesn't do the
handling that schroot does, so minimal.c can't even spawn bash -i
normally.

Thanks for looking at this, I'll report back once I isolate what bash -i
is doing differently from bash.

-Kees

-- 
Kees Cook                                            @debian.org