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".
>> Not sure what you expect from "vserver exec" but it is intended
>> to execute processes inside the guest after all.
>> If the guest has no reaper/init running, every top level guest
>> process will become a child of a host process.
> Yes, but how can a host process become a child of a guest
> process in that way?
Ah, I obviusly misread that part _twice_, sorry :)
> Could some strange corner case/bug in setpgid cause that?
Maybe.
>>> Since the guest process is in the guest's PID namespace, tools
>>> on the host fail to react accordingly, e.g. bash job-control
>>> gets stuck or start-stop-daemon reacts unexpected.
>> Maybe details about kernel/patch/util-vserver version as well
>> as the problematic command sequence which causes the "unexpected"
>> behaviour plus a description what the "expected" behaviour would
>> be would help a lot.
> Version should be the latest available for download:
> Linux version 3.14.17-vs2.3.6.13 (root@localhost) (gcc version 4.8.2) #1 SMP
> Tue Sep 16 09:13:43 UTC 2014
> Command sequence is
> start-stop-daemon --start --background --make-pidfile --pidfile
> "/var/run/xxxx.pid" --exec /usr/bin/socat EXEC:host-stdin-bridge
> "EXEC:vserver somename exec guest-stdout-bridge,nofork=1"
> When running the command, the host-stdin-bridge process running
> on the host will become the child of the guest-stdout-bridge
> command running in the guest, thus host process returning a
> guest-PID via getppid
Strange indeed.
Do you, by any chance, know if that works with LXC?
> I would expect the host process to have start-stop-daemon as
> parent at first, after termination if start-stop-daemon, I
> would guess getppid()=1 should be it for the host process.
>>> Some questions to that:
>>> * Can someone give a hint, how this could happen, thus being
>>> able to attempt to fix the problem for now using a workaround?
>>> * Is this caused by known behavior of vserver exec and misuse
>>> from my side?
>>> * No matter if misuse or bug, should this case be prevented
>>> since it should also cause security risks?
>>> A host process uses the parent pid of itself or another host
>>> process, but parent pid is from guest namespace. So from my
>>> understanding it could collide with PIDs from host namespace,
>>> thus host process might operate on arbitrary other host
>>> process, e.g. signalling or modifying it or just like with
>>> bash, getting stuck running wait(-1) in endless loop?
>> Let's get some details first, thanks,
> OK
Best,
Herbert
Received on Mon Oct 13 13:13:12 2014