Subject: PID namespace issue with VServer
From: Thomas Calderon <calderon.thomas@gmail.com>
Date: Mon, 1 Jun 2015 16:58:28 +0200
Mon, 1 Jun 2015 16:58:28 +0200
Hi,

I would like to report an issue that I observed while performing stress
tests of
an application. This is a simple model where daemon forks child processes
that
handle client connections.

What is observed is that the application is launched from outside the
VServer
context, then it jails itself using the provided API and enters a new
namespace
PID. Let's say the ancestor PID was 3541 prior to be jailed, in the
context, it
will be 1 as expected.

Then we start the stress test, the forking daemon will spawn child
processes.
However, when one of the child reaches the PID of the ancestor (3541) in the
jail, the daemon is blocked, no more connections are processed.

This triggers no stack trace or warning on the system. We do not seem to
reach
some limits. Thus, this behavior seems wrong.

I am running Linux kernel x86 version 3.2.69 with GrSecurity + VServer
2.3.2.17.

Many thanks for any feedback on this,

Thomas Calderon


Hi,

I would like to report an issue that I observed while performing stress tests of
an application. This is a simple model where daemon forks child processes that
handle client connections.

What is observed is that the application is launched from outside the VServer
context, then it jails itself using the provided API and enters a new namespace
PID. Let's say the ancestor PID was 3541 prior to be jailed, in the context, it
will be 1 as expected.

Then we start the stress test, the forking daemon will spawn child processes.
However, when one of the child reaches the PID of the ancestor (3541) in the
jail, the daemon is blocked, no more connections are processed.

This triggers no stack trace or warning on the system. We do not seem to reach
some limits. Thus, this behavior seems wrong.

I am running Linux kernel x86 version 3.2.69 with GrSecurity + VServer 2.3.2.17.

Many thanks for any feedback on this,

Thomas Calderon