> Von: Daniel Hokka Zakrisson [mailto:firstname.lastname@example.org]
> Fiedler Roman wrote:
> > Hi,
> >> Von: Herbert Poetzl [mailto:email@example.com]
> >> On Mon, Oct 13, 2014 at 11:47:48AM +0000, Fiedler Roman wrote:
> >> > Hi,
> >> > Thanks for your reply,
> >> >> Von: Herbert Poetzl [mailto:firstname.lastname@example.org]
> >> >> 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
> > 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
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  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