Re: Bug in interaction with pid namespaces

[Bart Schaefer <schaefer@brasslantern.com>]

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.

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

} 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?