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

From: Daniel Hokka Zakrisson <daniel_at_hozac.com>
Date: Mon 13 Oct 2014 - 19:36:21 BST
Message-ID: <d52a8c2c77c6cebf4673f6f95e7d09da.squirrel@intranet.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.

> [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.

> * 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.

Daniel

> Roman
>
Received on Mon Oct 13 19:36:35 2014

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 13 Oct 2014 - 19:36:35 BST by hypermail 2.1.8