OpenVZ Forum - RDF feed
type: channel
items: [PATCH] namespaces: introduce sys_hijack (v4)
items: Re: [PATCH] namespaces: introduce sys_hijack (v4)

[PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: >From 945fe66259cd0cfdc2fe846287b7821e329a558c Mon Sep 17 00:00:00 2001 From: sergeh@us.ibm.com <hallyn@kernel.(none)> Date: Tue, 9 Oct 2007 08:30:30 -0700 Subject: [PATCH] namespaces: introduce sys_hijack (v4) Move most of do_fork() into a new do_fork_task() which acts on a new argument, task, rather than on current. do_fork() becomes a call to do_fork_task(current, ...). Introduce sys_hijack (for x86 only so far). It is like clone, but in place of a stack pointer (which is assumed null) it accepts a pid. The process identified by that pid is the one which is actually cloned. Some state - include the file table, the signals and sighand (and hence tty), and the ->parent are taken from the calling process. The effect is a sort of namespace enter. The following program uses sys_hijack to 'enter' all namespaces of the specified pid. For instance in one terminal, do mount -t cgroup -ons /cgroup hostname qemu ns_exec -u /bin/sh hostname serge echo $$ 1073 cat /proc/$$/cgroup ns:/node_1073 In another terminal then do hostname qemu cat /proc/$$/cgroup ns:/ hijack 1073 hostname serge cat /proc/$$/cgroup ns:/node_1073 sys_hijack is arch-dependent and is only implemented for i386 so far. Changelog: Aug 23: send a stop signal to the hijacked process (like ptrace does). Oct 09: Update for 2.6.23-rc8-mm2 (mainly pidns) Don't take task_lock under rcu_read_lock Send hijacked process to cgroup_fork() as the first argument. Removed some unneeded task_locks. ============================================================== hijack.c ============================================================== int do_clone_task(void) { execl("/bin/sh", "/bin/sh", NULL); } int main(int argc, char *argv[]) { int pid; int ret; int status; if (argc < 2) return 1; pid = atoi(argv[1]); ret = syscall(327, SIGCHLD, pid, NULL, NULL); if (ret == 0) { return do_clone_task(); } else if (ret < 0) { perror("sys_hijack"); } else { printf("waiting on cloned process %d\n", ret); while (waitpid(ret, &status, __WCLONE) !=…
creator: serue
date: 2007-10-09T20:09:28-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Serge E. Hallyn wrote: >>From 945fe66259cd0cfdc2fe846287b7821e329a558c Mon Sep 17 00:00:00 2001 > From: sergeh@us.ibm.com <hallyn@kernel.(none)> > Date: Tue, 9 Oct 2007 08:30:30 -0700 > Subject: [PATCH] namespaces: introduce sys_hijack (v4) > > Move most of do_fork() into a new do_fork_task() which acts on > a new argument, task, rather than on current. do_fork() becomes > a call to do_fork_task(current, ...). > > Introduce sys_hijack (for x86 only so far). It is like clone, but > in place of a stack pointer (which is assumed null) it accepts a > pid. The process identified by that pid is the one which is > actually cloned. Some state - include the file table, the signals > and sighand (and hence tty), and the ->parent are taken from the > calling process. hmm, I'm wondering how this is going to work for a process which would have unshared its device (pts) namespace. How are we going to link the pts living in different namespaces if the stdios of the hijacked process is using them ? like in the case of a shell, which is certainly something we would like to hijacked. it looks like a challenge for me. maybe I'm wrong. C. > The effect is a sort of namespace enter. The following program > uses sys_hijack to 'enter' all namespaces of the specified pid. > For instance in one terminal, do > > mount -t cgroup -ons /cgroup > hostname > qemu > ns_exec -u /bin/sh > hostname serge > echo $$ > 1073 > cat /proc/$$/cgroup > ns:/node_1073 Is there a reason to have the 'node_' prefix ? couldn't we just use $pid ? > In another terminal then do > > hostname > qemu > cat /proc/$$/cgroup > ns:/ > hijack 1073 > hostname > serge > cat /proc/$$/cgroup > ns:/node_1073 > > sys_hijack is arch-dependent and is only implemented for i386 so far. and worked on my qemu. Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-10T17:06:23-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > Serge E. Hallyn wrote: > >>From 945fe66259cd0cfdc2fe846287b7821e329a558c Mon Sep 17 00:00:00 2001 > > From: sergeh@us.ibm.com <hallyn@kernel.(none)> > > Date: Tue, 9 Oct 2007 08:30:30 -0700 > > Subject: [PATCH] namespaces: introduce sys_hijack (v4) > > > > Move most of do_fork() into a new do_fork_task() which acts on > > a new argument, task, rather than on current. do_fork() becomes > > a call to do_fork_task(current, ...). > > > > Introduce sys_hijack (for x86 only so far). It is like clone, but > > in place of a stack pointer (which is assumed null) it accepts a > > pid. The process identified by that pid is the one which is > > actually cloned. Some state - include the file table, the signals > > and sighand (and hence tty), and the ->parent are taken from the > > calling process. > > hmm, I'm wondering how this is going to work for a process which > would have unshared its device (pts) namespace. How are we going > to link the pts living in different namespaces if the stdios of the > hijacked process is using them ? like in the case of a shell, which > is certainly something we would like to hijacked. > > it looks like a challenge for me. maybe I'm wrong. Might be a problem, but tough to address that until we actually have a dev ns or devpts ns and established semantics. Note the filestruct comes from current, not the hijack target, so presumably we can work around the tty issue in any case by keeping an open file across the hijack? For instance, use the attached modified version of hijack.c which puts a writeable fd for /tmp/helloworld in fd 5, then does hijack, then from the resulting shell do echo ab >&5 So we should easily be able to work around it. Or am i missing something? > > The effect is a sort of namespace enter. The following program > > uses sys_hijack to 'enter' all namespaces of the specified pid. > > For instance in one terminal, do > > > > mount -t cgroup -ons /cgroup > > hostname > > qemu > > ns_ex…
creator: serue
date: 2007-10-10T18:32:34-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Serge E. Hallyn (serue@us.ibm.com): > >From 945fe66259cd0cfdc2fe846287b7821e329a558c Mon Sep 17 00:00:00 2001 > From: sergeh@us.ibm.com <hallyn@kernel.(none)> > Date: Tue, 9 Oct 2007 08:30:30 -0700 > Subject: [PATCH] namespaces: introduce sys_hijack (v4) > > Move most of do_fork() into a new do_fork_task() which acts on > a new argument, task, rather than on current. do_fork() becomes > a call to do_fork_task(current, ...). > > Introduce sys_hijack (for x86 only so far). It is like clone, but > in place of a stack pointer (which is assumed null) it accepts a > pid. The process identified by that pid is the one which is > actually cloned. Some state - include the file table, the signals > and sighand (and hence tty), and the ->parent are taken from the > calling process. > > The effect is a sort of namespace enter. The following program > uses sys_hijack to 'enter' all namespaces of the specified pid. > For instance in one terminal, do > > mount -t cgroup -ons /cgroup > hostname > qemu > ns_exec -u /bin/sh > hostname serge > echo $$ > 1073 > cat /proc/$$/cgroup > ns:/node_1073 > > In another terminal then do > > hostname > qemu > cat /proc/$$/cgroup > ns:/ > hijack 1073 > hostname > serge > cat /proc/$$/cgroup > ns:/node_1073 > > sys_hijack is arch-dependent and is only implemented for i386 so far. > > Changelog: > Aug 23: send a stop signal to the hijacked process > (like ptrace does). > Oct 09: Update for 2.6.23-rc8-mm2 (mainly pidns) > Don't take task_lock under rcu_read_lock > Send hijacked process to cgroup_fork() as > the first argument. > Removed some unneeded task_locks. Thanks to Cedric for finding an oops when using pid namespaces. The following patch fixes the problem. In addition, to hijack a process in another pid namespace, the hijack.c test program needs to be updated to do waitpid as while(waitpid(-1, &status, __WALL) != -1) ; as shown below: ============================================================== hijack.c ==============================…
creator: serue
date: 2007-10-11T22:15:34-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Serge E. Hallyn wrote: > Quoting Serge E. Hallyn (serue@us.ibm.com): >> >From 945fe66259cd0cfdc2fe846287b7821e329a558c Mon Sep 17 00:00:00 2001 >> From: sergeh@us.ibm.com <hallyn@kernel.(none)> >> Date: Tue, 9 Oct 2007 08:30:30 -0700 >> Subject: [PATCH] namespaces: introduce sys_hijack (v4) >> >> Move most of do_fork() into a new do_fork_task() which acts on >> a new argument, task, rather than on current. do_fork() becomes >> a call to do_fork_task(current, ...). >> >> Introduce sys_hijack (for x86 only so far). It is like clone, but >> in place of a stack pointer (which is assumed null) it accepts a >> pid. The process identified by that pid is the one which is >> actually cloned. Some state - include the file table, the signals >> and sighand (and hence tty), and the ->parent are taken from the >> calling process. >> >> The effect is a sort of namespace enter. The following program >> uses sys_hijack to 'enter' all namespaces of the specified pid. >> For instance in one terminal, do >> >> mount -t cgroup -ons /cgroup >> hostname >> qemu >> ns_exec -u /bin/sh >> hostname serge >> echo $$ >> 1073 >> cat /proc/$$/cgroup >> ns:/node_1073 >> >> In another terminal then do >> >> hostname >> qemu >> cat /proc/$$/cgroup >> ns:/ >> hijack 1073 >> hostname >> serge >> cat /proc/$$/cgroup >> ns:/node_1073 >> >> sys_hijack is arch-dependent and is only implemented for i386 so far. >> >> Changelog: >> Aug 23: send a stop signal to the hijacked process >> (like ptrace does). >> Oct 09: Update for 2.6.23-rc8-mm2 (mainly pidns) >> Don't take task_lock under rcu_read_lock >> Send hijacked process to cgroup_fork() as >> the first argument. >> Removed some unneeded task_locks. > > Thanks to Cedric for finding an oops when using pid namespaces. The > following patch fixes the problem. it works fine now. Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containe…
creator: Cedric Le Goater
date: 2007-10-12T09:30:33-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: >> hmm, I'm wondering how this is going to work for a process which >> would have unshared its device (pts) namespace. How are we going >> to link the pts living in different namespaces if the stdios of the >> hijacked process is using them ? like in the case of a shell, which >> is certainly something we would like to hijacked. >> >> it looks like a challenge for me. maybe I'm wrong. > > Might be a problem, but tough to address that until we actually > have a dev ns or devpts ns and established semantics. > > Note the filestruct comes from current, not the hijack target, so > presumably we can work around the tty issue in any case by > keeping an open file across the hijack? > > For instance, use the attached modified version of hijack.c > which puts a writeable fd for /tmp/helloworld in fd 5, then > does hijack, then from the resulting shell do > > echo ab >&5 > > So we should easily be able to work around it. yes. it should. > Or am i missing something? I guess we need to work a little more on the pts/device namespace to see how it interacts. >>> The effect is a sort of namespace enter. The following program >>> uses sys_hijack to 'enter' all namespaces of the specified pid. >>> For instance in one terminal, do >>> >>> mount -t cgroup -ons /cgroup >>> hostname >>> qemu >>> ns_exec -u /bin/sh >>> hostname serge >>> echo $$ >>> 1073 >>> cat /proc/$$/cgroup >>> ns:/node_1073 >> Is there a reason to have the 'node_' prefix ? couldn't we just >> use $pid ? > > Good question. It's just how the ns-cgroup does it... If you want to > send in a patch to change that, I'll ack it. just below. I gave a quick look to the ns subsystem and didn't see how the node_$pid was destroyed. do we have to do a rmdir ? Thanks, C. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> --- kernel/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: 2.6.23-mm1/kernel/cgroup.c =================================================================== --- 2.6.23-mm1.orig/kernel/cgroup.c +++…
creator: Cedric Le Goater
date: 2007-10-16T08:51:04-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: One thought on this - could we make the API have a "which" parameter that indicates the type of thing being acted upon? E.g., like sys_setpriority(), which can specify the target as a process, a pgrp or a user. Right now the target would just be a process, but I'd really like the ability to be able to specify an fd on a cgroup directory to indicate that I want the child to inherit from that cgroup's namespaces. That way you wouldn't need to keep a child process alive in the namespace just to act as a hijack target. Paul On 10/9/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > >From 945fe66259cd0cfdc2fe846287b7821e329a558c Mon Sep 17 00:00:00 2001 > From: sergeh@us.ibm.com <hallyn@kernel.(none)> > Date: Tue, 9 Oct 2007 08:30:30 -0700 > Subject: [PATCH] namespaces: introduce sys_hijack (v4) > > Move most of do_fork() into a new do_fork_task() which acts on > a new argument, task, rather than on current. do_fork() becomes > a call to do_fork_task(current, ...). > > Introduce sys_hijack (for x86 only so far). It is like clone, but > in place of a stack pointer (which is assumed null) it accepts a > pid. The process identified by that pid is the one which is > actually cloned. Some state - include the file table, the signals > and sighand (and hence tty), and the ->parent are taken from the > calling process. > > The effect is a sort of namespace enter. The following program > uses sys_hijack to 'enter' all namespaces of the specified pid. > For instance in one terminal, do > > mount -t cgroup -ons /cgroup > hostname > qemu > ns_exec -u /bin/sh > hostname serge > echo $$ > 1073 > cat /proc/$$/cgroup > ns:/node_1073 > > In another terminal then do > > hostname > qemu > cat /proc/$$/cgroup > ns:/ > hijack 1073 > hostname > serge > cat /proc/$$/cgroup > ns:/node_1073 > > sys_hijack is arch-dependent and is only implemented for i386 so far. > > Changelog: > Aug 23: send a stop signal to the hijacked process > (like ptrace does). > Oct 09: Update for 2.6.23-rc8-mm2 (mainly pid…
creator: Paul Menage
date: 2007-10-16T09:09:44-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > > >> hmm, I'm wondering how this is going to work for a process which > >> would have unshared its device (pts) namespace. How are we going > >> to link the pts living in different namespaces if the stdios of the > >> hijacked process is using them ? like in the case of a shell, which > >> is certainly something we would like to hijacked. > >> > >> it looks like a challenge for me. maybe I'm wrong. > > > > Might be a problem, but tough to address that until we actually > > have a dev ns or devpts ns and established semantics. > > > > Note the filestruct comes from current, not the hijack target, so > > presumably we can work around the tty issue in any case by > > keeping an open file across the hijack? > > > > For instance, use the attached modified version of hijack.c > > which puts a writeable fd for /tmp/helloworld in fd 5, then > > does hijack, then from the resulting shell do > > > > echo ab >&5 > > > > So we should easily be able to work around it. > > yes. it should. > > > Or am i missing something? > > I guess we need to work a little more on the pts/device namespace > to see how it interacts. > > >>> The effect is a sort of namespace enter. The following program > >>> uses sys_hijack to 'enter' all namespaces of the specified pid. > >>> For instance in one terminal, do > >>> > >>> mount -t cgroup -ons /cgroup > >>> hostname > >>> qemu > >>> ns_exec -u /bin/sh > >>> hostname serge > >>> echo $$ > >>> 1073 > >>> cat /proc/$$/cgroup > >>> ns:/node_1073 > >> Is there a reason to have the 'node_' prefix ? couldn't we just > >> use $pid ? > > > > Good question. It's just how the ns-cgroup does it... If you want to > > send in a patch to change that, I'll ack it. > > just below. > > I gave a quick look to the ns subsystem and didn't see how the node_$pid > was destroyed. do we have to do a rmdir ? > > Thanks, > > > C. > > Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Thanks. Acked-by: Serge Hallyn <serue@us.ibm.com>…
creator: serue
date: 2007-10-16T14:31:52-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Paul Menage (menage@google.com): > One thought on this - could we make the API have a "which" parameter > that indicates the type of thing being acted upon? E.g., like > sys_setpriority(), which can specify the target as a process, a pgrp > or a user. > > Right now the target would just be a process, but I'd really like the > ability to be able to specify an fd on a cgroup directory to indicate > that I want the child to inherit from that cgroup's namespaces. That > way you wouldn't need to keep a child process alive in the namespace > just to act as a hijack target. Good idea. I would in fact originally have taken a cgroup instead of a pid, but wasn't sure how best to identify the cgroup. Originally I was more worried about pid exiting/wraparound, but then decided that with a real container the container_init can't go away until the container goes away anyway. Anyway, I can go ahead and add 'int which' to the parameter list now, and leave the details of how to specify a cgroup for later. That way at least the api won't fundamentally change again. Good idea, thanks. -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-10-16T14:37:44-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: On 10/16/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > pid, but wasn't sure how best to identify the cgroup. Originally I was > more worried about pid exiting/wraparound, but then decided that with a > real container the container_init can't go away until the container goes > away anyway. For those "real containers" that have init. Not everything is going to need that level of virtualization, particularly if you're primarily interested in isolation. > > Anyway, I can go ahead and add 'int which' to the parameter list now, > and leave the details of how to specify a cgroup for later. That way at > least the api won't fundamentally change again. Great, thanks. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-10-16T16:32:16-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Paul Menage (menage@google.com): > On 10/16/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > > pid, but wasn't sure how best to identify the cgroup. Originally I was > > more worried about pid exiting/wraparound, but then decided that with a > > real container the container_init can't go away until the container goes > > away anyway. > > For those "real containers" that have init. Not everything is going to > need that level of virtualization, particularly if you're primarily > interested in isolation. Currently every pid namespace's pid==1 must stick around as long as the pid namespace does. If you kill the pid==1, all processes in the container are killed. > > Anyway, I can go ahead and add 'int which' to the parameter list now, > > and leave the details of how to specify a cgroup for later. That way at > > least the api won't fundamentally change again. > > Great, thanks. Since the goal here is to get the API right, do you know how we expect to send the cgroup in? A string? Currently my prototype is +asmlinkage long sys_hijack(unsigned long flags, int which, pid_t pid, + const char __user *cgroup); But that doesn't seem quite right. At that point we just ditch 'which' and use cgroups if it's not NULL, use pid otherwise... Thoughts? thanks, -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-10-16T18:57:37-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: On 10/16/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > > Currently every pid namespace's pid==1 must stick around as long as the > pid namespace does. If you kill the pid==1, all processes in the > container are killed. What about people who aren't using pid namespaces? > > > > Anyway, I can go ahead and add 'int which' to the parameter list now, > > > and leave the details of how to specify a cgroup for later. That way at > > > least the api won't fundamentally change again. > > > > Great, thanks. > > Since the goal here is to get the API right, do you know how we expect > to send the cgroup in? A string? My thought was to use an fd on an open cgroup directory - that can be trivially translated into a cgroup. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-10-16T19:03:17-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Paul Menage (menage@google.com): > On 10/16/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > > > > Currently every pid namespace's pid==1 must stick around as long as the > > pid namespace does. If you kill the pid==1, all processes in the > > container are killed. > > What about people who aren't using pid namespaces? Not really isolated? :) > > > > Anyway, I can go ahead and add 'int which' to the parameter list now, > > > > and leave the details of how to specify a cgroup for later. That way at > > > > least the api won't fundamentally change again. > > > > > > Great, thanks. > > > > Since the goal here is to get the API right, do you know how we expect > > to send the cgroup in? A string? > > My thought was to use an fd on an open cgroup directory - that can be > trivially translated into a cgroup. Oh good, so I can just pass in a single arg id, so asmlinkage long sys_hijack(unsigned long clone_flags, int which, unsigned long id); ? _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-10-16T19:12:00-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: On 10/16/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > > Oh good, so I can just pass in a single arg id, so > > asmlinkage long sys_hijack(unsigned long clone_flags, int which, > unsigned long id); > Sounds good. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-10-16T19:29:36-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: On 10/16/07, Serge E. Hallyn <serue@us.ibm.com> wrote: > > Oh good, so I can just pass in a single arg id, so > > asmlinkage long sys_hijack(unsigned long clone_flags, int which, > unsigned long id); > Sounds good. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-10-16T19:32:05-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: > asmlinkage long sys_hijack(unsigned long clone_flags, int which, > unsigned long id); I expect to get more explanation of the arguments in the patch you are going to send :) 'which' is used as a switch for 'id' : pid or fd on a open cgroup directory. right ? Thanks, C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-10-16T21:28:22-00:00

Re: [PATCH] namespaces: introduce sys_hijack (v4)
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > > > asmlinkage long sys_hijack(unsigned long clone_flags, int which, > > unsigned long id); > > I expect to get more explanation of the arguments in the patch > you are going to send :) There'll have to be a man page at some point (ugh). > 'which' is used as a switch for 'id' : pid or fd on a open cgroup > directory. right ? Yup. -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-10-16T21:32:00-00:00