[Lxc-users] PID namespace behavior

[Arun M]

On Wed, Apr 11, 2012 at 7:52 PM, Serge Hallyn <serge.hallyn at canonical.com>wrote:

> Quoting Arun M (arunmahadevaiyer at gmail.com):
> > Hello,
> >
> > I am observing that if two containers are spawned via lxc-execute and if
> > these happen to be in  the same process group, a process inside one
> > container can terminate the second container by sending a SIGTERM to the
> > process group.
> >
> >
> > Code snippet of the test program that was running inside the container
> (via
> > lxc-execute):-
> > --
> > void handle_term(int sig)
> > {
> >   signal(SIGTERM, SIG_DFL);
> >   kill(0, SIGTERM);
> > }
> >
> > int main()
> > {
> >   signal(SIGTERM, handle_term);
> >   sleep(3600);
> > }
> > ----
> >
> > I forked two copies of this via lxc-execute and made sure that they have
> > the same process group ID and sent a SIGTERM to the first lxc-execute.
> >
> > The second container (where SIGTERM was not sent) apparently gets a
> SIGTERM
> > from PID 2 of the first container.
> >
> > ---
> > write(3, "    lxc-execute 1334131101.756 INFO     lxc_start - received
> >  signal 15 from pid 2, uid 36886\n", 94) = 94
> > write(3, "    lxc-execute 1334131101.756 INFO     lxc_start - forwarded
> > signal 15 to pid 14875\n", 85) = 85
> > ---
> >
> > Is this expected behavior ? Shouldn't two process in independent PID
> > namespaces get their own copy of process group IDs ?
>
> Interesting case.  My first guess was that it is because lxc-execute
> doesn't
> do a setsid() or setpgrp() and that clone(CLONE_NEWPID) doesn't do that for
> you as I assumed.  But when I try:
>
> handlesignal() {
>        echo hi htere
> }
> trap handlesignal USR1
> cat > /root/killusr1.c << EOF
> #include <stdio.h>
> #include <sys/types.h>
> #include <signal.h>
>
> int main()
> {
>                kill(0, SIGUSR1);
> }
> EOF
> gcc -o /root/killusr1 /root/killusr1.c
> lxc-unshare -s PID /root/killusr1
>
> the parent shell doesn't get the signal.
>
> So I'm not sure offhand what is going on.  I'll wait and see if someone
> else
> knows offhand, otherwise will look into it more.  Cause it's interesting.
>
> thanks,
> -serge
>

I guess the unshare and shell does not belong to the same process group. I
am able to reproduce with the following code.

cat > pgrp.c <<EOF
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <alloca.h>
#include <sched.h>
#include <sys/types.h>
#include <sys/wait.h>


void handle_usr1()
{
printf("PID = %d, got usr1\n", getpid());
}

int do_child(void *a)
{
printf("Child pgrp = %d\n",getpgrp());
sleep(10);
kill(0, SIGUSR1);
return 0;
}

int main()
{
pid_t pid;
int status;
long stack_size = sysconf(_SC_PAGESIZE);
void *stack = alloca(stack_size);

signal(SIGUSR1, handle_usr1);

if ( (pid = clone(do_child, stack + stack_size, CLONE_NEWPID, NULL)) == -1)
{
perror("clone");
return -1;
}

printf("Parent pgrp = %d\n",getpgrp());

waitpid(pid, &status, __WCLONE);

return 0;
}
EOF

$ gcc pgrp.c -o pgrp
$ sudo ./pgrp
Parent pgrp = 21135
Child pgrp = 0
PID = 1, got usr1
PID = 21136, got usr1
User defined signal 1

----

Though the child pgrp is 0 in child, outside the namespace both the parent
and child seem to be having the same pgrp id and hence the signal is
delivered to the parent as well.

Thanks,
Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20120412/aafe2db7/attachment.html>