Subject: AW: [vserver] Problem with host process ending up to be child of guest process
From: Fiedler Roman <>
Date: Tue, 14 Oct 2014 08:06:50 +0000
Tue, 14 Oct 2014 08:06:50 +0000

> Von: Daniel Hokka Zakrisson []
> Hi,
> Fiedler Roman wrote:
> > Hi,
> >
> >> Von: Herbert Poetzl []
> >>
> >> On Mon, Oct 13, 2014 at 11:47:48AM +0000, Fiedler Roman wrote:
> >> > Hi,
> >>
> >> > Thanks for your reply,
> >>
> >> >> Von: Herbert Poetzl []
> >>
> >> >> On Mon, Oct 13, 2014 at 08:52:36AM +0000, Fiedler Roman wrote:
> >> >>> Hello List,
> >>
> >> >>> Analyzing a problem today, It seems the the root cause is, that
> >> >>> a host process ended up being the child of a guest process
> >> >>> after using "vserver exec".
> >> ....
> >>
> >> Strange indeed.
> >> Do you, by any chance, know if that works with LXC?
> >
> > I've constructed a simpler testcase and ran it with vserver and LXC (I
> > noted
> > host/guest in the prompt for distinction):
> >
> > * vserver:
> >
> > host# socat "EXEC:/bin/sleep 1000" "EXEC:vserver somename exec
> /bin/sleep
> > 1001,nofork=1"
> So nofork here means that socat will execute it in the socat process, when
> it is done setting up
> the other processes. So essentially, you are telling socat to make the
> first process a child of the
> vserver ... exec. vserver is really not a factor here.

OK, so the host process ending up with a parent in another pid namespace is 
the mere consequence of the (sometimes unknown or unpredictable) 
forking-behavior of the the parent process of both.

It seems, that the LXC tools care to avoid this, so there might be a reason 
for that.

Since we don't know, if there are security implications and behavior might not 
be trivial to predict (how does upstart or start-stop-daemon fork depending on 
their options and may there be risky configurations in old, current of future 
versions?), vserver project documentation, e.g. on [1] should state, that it 
must always be called via a stable intermediate process to avoid re-parenting, 
or better not even used at all (see comments below).

> > [snip...]
> > So asking again for opinions:
> > * Can someone give a hint, how this could happen, thus being able to
> > attempt
> > to fix the problem for now using a workaround?
> Don't tell socat to do that. Tell it to do what you want.

OK, here I can do that. But from my point of view, documentation should be 
changed to avoid other people having the same problem too.

> > * No matter if misuse or bug, should this case be prevented  since it
> > should
> > also cause security risks due to host/guest pidns mixup?
> There is no mixup. All pids are valid in the contexts they appear. As
> util-vserver is not yet using pid
> namespaces, there is only one.

Sorry, I can't follow that completely. If a host process shows a parent pid, 
which cannot be found on the host and causes host tools to lock-up, there is 
at least some room for improvement.

Am I mistaken, that basically it boils down to this: There is no secure and 
stable way to communicate from host with the guest without opening a network 
or socket connection to a process already running in guest, that was started 
by guest init process?

If yes, this should also be made clear in documentation, to avoid any 
problematic constructs.



["application/pkcs7-signature" not shown]