Bug in interaction with pid namespaces

[Chirantan Ekbote <chirantan@google.com>]

Hi,

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.  This can be minimally reproduced by running:

    unshare -p -f --mount-proc zsh -l

and then running

    ps o pid,pgid,comm

inside the newly created 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).  If you then press ctrl-c, zsh will exit rather than just show the
prompt again.  I think this can be fixed with the following patch:

diff --git a/Src/jobs.c b/Src/jobs.c
index a668b07..8c4254a 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -2734,7 +2734,7 @@ acquire_pgrp(void)
     long ttpgrp;
     sigset_t blockset, oldset;

-    if ((mypgrp = GETPGRP()) > 0) {
+    if ((mypgrp = GETPGRP()) >= 0) {
        long lastpgrp = mypgrp;
        sigemptyset(&blockset);
        sigaddset(&blockset, SIGTTIN);

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", which is not the intention of the
call at all.

What's the proper way to fix this?

Thanks,
Chirantan



[1] http://lwn.net/Articles/531419/