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