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

From: Fiedler Roman <Roman.Fiedler_at_ait.ac.at>
Date: Mon 13 Oct 2014 - 14:59:56 BST
Message-ID: <2ECE9D9EEF1F524185270138AE23265947D15E14@S0MSMAIL111.arc.local>

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"

host# ps aux | grep sleep
root 19625 0.0 0.0 5916 616 pts/3 S+ 13:45 0:00 /bin/sleep
1000

host# cat /proc/19625/status | grep Pid
Pid: 19625
PPid: 19624
TracerPid: 0

guest# ps aux | grep sleep
root 19624 0.0 0.0 3752 540 pts/3 S+ 13:45 0:00 /bin/sleep
1001

So host process is child of guest process:

* lxc:

If I understand correctly, the corresponding call for LXC would be

host# socat "EXEC:/bin/sleep 1000" "EXEC:lxc-attach --name test-guest --
/bin/sleep 1001,nofork=1"

host# ps aux | grep sleep
root 17956 0.0 0.5 3872 1452 pts/1 S 13:50 0:00 lxc-attach
--name test-guest -- /bin/sleep 1001
root 17957 0.0 0.2 3752 540 pts/1 S 13:50 0:00 /bin/sleep
1000
root 17959 0.0 0.2 4228 540 pts/1 S 13:50 0:00 /bin/sleep
1001

host# cat /proc/17957/status | grep Pid
Pid: 17957
PPid: 17956
TracerPid: 0

guest# ps aux | grep sleep
root 503 0.0 0.2 4228 540 ? S+ 13:50 0:00 /bin/sleep
1001

So with LXC, the main differences seem to be:
* lxc-attach does not exec the "sleep 1001" in the guest context, but as own
child. So using it as parent for "sleep 1000" still keeps the ppid reference
valid in the host-pid-ns
* the second "sleep 1001" process is visible both in host and hence even
reparenting would still make "sleep 1000" ppid point to valid host-pid-ns
pid

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?
* No matter if misuse or bug, should this case be prevented since it should
also cause security risks due to host/guest pidns mixup?

Roman

Received on Mon Oct 13 15:00:39 2014
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 13 Oct 2014 - 15:00:40 BST by hypermail 2.1.8