AW: [vserver] Problem with host process ending up to be child of guest process

From: Fiedler Roman <Roman.Fiedler_at_ait.ac.at>
Date: Tue 14 Oct 2014 - 09:06:50 BST
Message-ID: <2ECE9D9EEF1F524185270138AE23265947D161A9@S0MSMAIL111.arc.local>

Hi,

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

Roman

[1] http://linux-vserver.org/util-vserver:Useful_commands

Received on Tue Oct 14 09:07:04 2014
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 14 Oct 2014 - 09:07:04 BST by hypermail 2.1.8