Re: Bug in interaction with pid namespaces

[Chirantan Ekbote <chirantan@google.com>]

On Tue, Dec 16, 2014 at 10:27 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Dec 16,  3:07pm, Chirantan Ekbote wrote:
> }
> } I think I've found an issue with the way zsh interacts with pid
> } namespaces [1]. Specifically the problem is that when zsh is launched
> } immediately following the creation of a new pid namespace it doesn't
> } take ownership of the process group, causing things like SIGINT to be
> } sent to the process that spawned zsh rather than zsh itself.
>
> Considering that pid namespaces are a very recent invention compared to
> zsh, this is hardly surprising.  It was never meant to be used as a
> replacement for init.
>

We're not trying to use zsh as a replacement for init.  I first
noticed this issue because the chrome os build system recently
switched to using pid namespaces in the build chroot.  I only
mentioned the unshare method because I figured you wouldn't want to
set up the entire chrome os build system just to reproduce this
problem ;-)  So the fact that it ends up as pid 1 is a bit of a red
herring here.  In the actual workflow where this is an issue for me,
the pid is somewhere in the 240 to 270 range and zsh is only meant to
behave like a regular shell.

> } The expected result is that the pgid for zsh should be the same as its
> } pid, indicating that zsh has become the leader of a new process group.
> } Instead I see that zsh has pgid 0 and a different pid (usually 1).
>
> How often is it not 1 ?  The first process in the namespace should always
> get pid 1, if I'm reading correctly.  Nevertheless ...
>
> } I think this can be fixed with the following patch:
> }
> } -    if ((mypgrp = GETPGRP()) > 0) {
> } +    if ((mypgrp = GETPGRP()) >= 0) {
>
> I don't see any reason not to make that change ...
>

Excellent.  Should I re-send it as a proper patch?

> } but this brings up another problem. When zsh exits it tries to restore
> } the original process group using setpgrp(0, origpgrp). This is an
> } issue when origpgrp is 0 because setpgrp(0, 0) actually means "set the
> } process group of the calling process to be the same as its pid"
>
> I'm not familiar enough with pid namespaces to answer authoritatively,
> but my understanding is that when the first process in the namespace
> exits, the entire namespace ceases to exist -- sy why does this matter
> at all?  The pgrp should already be the same as the pid at that point,
> and the whole point of the namespace is that processes inside the
> namespace can't directly reference a pid or pgrp outside the namespace,
> so setpgrp(0,0) should be unnecessary but a no-op.
>
> What's the actual problem that's left over after zsh has exited?

So the problem is that on exit zsh gives a warning:

    zsh: can't set tty pgrp: no such process

which I thought was due to the call to setpgrp() but is actually in
the call to attachtty().  I'm having a trouble parsing that function
to figure out why that warning is happening though.