OpenVZ Forum - RDF feed
type: channel
items: [RFC] ns containers (v2): namespace entering
items: [PATCH 1/4] namespaces: make get_nsproxy nonstatic
items: [PATCH 2/4] namespace container: move nsproxy setting code
items: [PATCH 3/4] namespace containers: add nsproxy to nscont struct
items: [PATCH 4/4] namespace containers: implement enter into existing container
items: Re: [RFC] ns containers (v2): namespace entering

[RFC] ns containers (v2): namespace entering
type: item
description: (Updated patchset addressing Paul's comments. Still looking more for discussion on functionality, but barring much of that I guess I'll do something with tsk->fs then send the set to lkml) The following patchset uses the ns container subsystem to implement namespace entering. It applies over the container patchset Paul sent out earlier today. = Usage = Following is example usage: mkdir /container_ns mount -t container -ons nsproxy /container_ns (start screen with two windows) (screen one) (unshare uts namespace) hostname serge (screen two) hostname (shows old hostname) echo $$ > /container_ns/node1/tasks (assuming node1 is screen one's new container) hostname (shows 'serge') Of course to get a useful result with the mounts namespace, we would have to convert the fs_struct to a namespace, and the mounts and fs_struct namespaces would be entered together. If we follow this path, the next step would be to add files under the container directory for each namespace, with ops->link defined such that you could mkdir /container_ns/new_container ln /container_ns/vserver1/network /container_ns/new_container/network echo $$ > /container_ns/new_container/tasks and be entered into a set of namespaces containing all of your defaults except network, which would come from vserver1. This is RFC not just on implementation, but also on whether to do it at all. If so, then for all namespace, or only some? And if not, how to facilitate virtual server management. = Security = Currently to enter a namespace, you must have CAP_SYS_ADMIN, and must be entering a container which is an immediate child of your current container. So from the root container you could enter container /vserver1, but from container /vserver1 you could not enter /vserver2 or the root container. This may turn out to be sufficient. If not, then LSM hooks should be added for namespace management. Four hooks for nsproxy management (create, compose, may_enter, and enter), as well as some security_ns_clone hook for each se…
creator: serue
date: 2007-02-19T22:14:46-00:00

[PATCH 1/4] namespaces: make get_nsproxy nonstatic
type: item
description: From: Serge E. Hallyn <serue@us.ibm.com> Subject: [PATCH 1/4] namespaces: make get_nsproxy nonstatic We'll need get_nsproxy accessible from containers code, but it is statically defined in kernel/nsproxy.c. Make it inline in include/linux/nsproxy.h. Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- include/linux/nsproxy.h | 5 +++++ kernel/nsproxy.c | 5 ----- 2 files changed, 5 insertions(+), 5 deletions(-) ad2cf2568b8fe9cf094905ec7370149baafc6495 diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h index c55f20b..0255e27 100644 --- a/include/linux/nsproxy.h +++ b/include/linux/nsproxy.h @@ -31,6 +31,11 @@ struct nsproxy { }; extern struct nsproxy init_nsproxy; +static inline void get_nsproxy(struct nsproxy *ns) +{ + atomic_inc(&ns->count); +} + struct nsproxy *dup_namespaces(struct nsproxy *orig); int copy_namespaces(int flags, struct task_struct *tsk); void get_task_namespaces(struct task_struct *tsk); diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c index d174d1f..1123ab2 100644 --- a/kernel/nsproxy.c +++ b/kernel/nsproxy.c @@ -23,11 +23,6 @@ struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy); -static inline void get_nsproxy(struct nsproxy *ns) -{ - atomic_inc(&ns->count); -} - void get_task_namespaces(struct task_struct *tsk) { struct nsproxy *ns = tsk->nsproxy; -- 1.1.6
creator: serue
date: 2007-02-19T22:15:36-00:00

[PATCH 2/4] namespace container: move nsproxy setting code
type: item
description: From: Serge E. Hallyn <serue@us.ibm.com> Subject: [PATCH 2/4] namespace container: move nsproxy setting code Move nsproxy setting code from clone and unshare into container_clone. Containers will need to do this for namespace entering functionality, so go ahead and move all setting of tsk->nsproxy there for simplicity/ consistency. The clone path (at kernel/nsproxy.c:copy_namespaces()) should be cleaned up: 1. The kfree(new_ns) on error at bottom may not be safe, if the nscont->nsproxy has already been set to it. However if it has been set, then container_clone() should have succeeded, so this *should* not be possible. 2. This path is taking a few extra copies - it sets the tsk->nsproxy to the new nsproxy early, then the swap_nsproxies() function copies it again. This should be cleaned up, but at least it is currently correct. Best thing would be to create a common helper for the unshare and clone cases. Changelog: Feb 14: move swap_nsproxies call into ns_container.c so as to leave nsproxy knowledge out of container.c Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- include/linux/nsproxy.h | 20 ++++++++++++++++++-- kernel/fork.c | 7 +------ kernel/ns_container.c | 4 +++- kernel/nsproxy.c | 2 +- 4 files changed, 23 insertions(+), 10 deletions(-) 225efc9fea0771d283d22c393d948492162c84d4 diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h index 0255e27..d11eb09 100644 --- a/include/linux/nsproxy.h +++ b/include/linux/nsproxy.h @@ -58,10 +58,26 @@ static inline void exit_task_namespaces( put_nsproxy(ns); } } + +static inline void swap_nsproxies(struct task_struct *tsk, struct nsproxy *nsproxy) +{ + struct nsproxy *oldnsp; + + task_lock(tsk); + oldnsp = tsk->nsproxy; + tsk->nsproxy = nsproxy; + get_nsproxy(nsproxy); + task_unlock(tsk); + put_nsproxy(oldnsp); +} + #ifdef CONFIG_CONTAINER_NS -int ns_container_clone(struct task_struct *tsk); +int ns_container_clone(struct task_struct *tsk, struct nsproxy *nsproxy); #else -static inline int ns_container_clone…
creator: serue
date: 2007-02-19T22:16:00-00:00

[PATCH 3/4] namespace containers: add nsproxy to nscont struct
type: item
description: From: Serge E. Hallyn <serue@us.ibm.com> Subject: [PATCH 3/4] namespace containers: add nsproxy to nscont struct Each ns container is associated with an nsproxy. Add that nsproxy to the nscont struct, set it when a container is auto- created on clone/unshare, and inc/dec the nsproxy to account for each container referencing it. Note that once the nscont->nsproxy is set, it will never change for the duration of the container's lifetime. Changelog: Feb 14: added ss->init_from_task() hook so ns_container can initialize a container's private data from a task on clone(). Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- Documentation/containers.txt | 9 +++++++++ include/linux/container.h | 1 + include/linux/nsproxy.h | 1 + kernel/container.c | 16 ++++++++++++++++ kernel/ns_container.c | 11 +++++++++++ 5 files changed, 38 insertions(+), 0 deletions(-) f863632142517f79ef885c238a8e5df238e8420c diff --git a/Documentation/containers.txt b/Documentation/containers.txt index 7918827..0001191 100644 --- a/Documentation/containers.txt +++ b/Documentation/containers.txt @@ -466,6 +466,15 @@ LL=manage_mutex The container system is about to destroy the passed container; the subsystem should do any necessary cleanup +int init_from_task(struct container *cont, struct task_struct *task) +LL=manage_mutex + +Called during a container_clone() call to allow differentiation +between a container created automatically and one created by hand. +A container created by hand inherits the nsproxy from the parent +container. A container created automatically inherits the nsproxy +from the task entering, which may have already done some unsharing. + int can_attach(struct container_subsys *ss, struct container *cont, struct task_struct *task) LL=manage_mutex diff --git a/include/linux/container.h b/include/linux/container.h index db2fc27..4c9c092 100644 --- a/include/linux/container.h +++ b/include/linux/container.h @@ -197,6 +197,7 @@ struct container_subsys { int (*create)(struct container_subs…
creator: serue
date: 2007-02-19T22:16:20-00:00

[PATCH 4/4] namespace containers: implement enter into existing container
type: item
description: From: Serge E. Hallyn <serue@us.ibm.com> Subject: [PATCH 4/4] namespace containers: implement enter into existing container Implement ns container subsys.can_attach(). Remove the constraint in can_attach() that the destination container must be unpopulated. When entering a container, if the container's nsproxy has not been set, set it to the parent container's. This will eventually support more complicated creation by composing namespaces from several nsproxies. Finally set the task's nsproxy to the container's to effect the namespace transition. Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- kernel/ns_container.c | 30 ++++++++++++++++++++++++++---- 1 files changed, 26 insertions(+), 4 deletions(-) fa70868cb500ac6e3319f6a5c04dac5e419cefbf diff --git a/kernel/ns_container.c b/kernel/ns_container.c index 1cc9cea..76044ad 100644 --- a/kernel/ns_container.c +++ b/kernel/ns_container.c @@ -23,6 +23,17 @@ static inline struct nscont *container_n struct nscont, css); } +/* for now we just take the parnet container nsproxy. + * eventually we will construct them based on file link activity */ +static void ns_create_nsproxy(struct nscont *ns, struct container *cont) +{ + struct container *parent = cont->parent; + struct nscont *parentns; + parentns = container_nscont(parent); + ns->nsproxy = parentns->nsproxy; + get_nsproxy(ns->nsproxy); +} + int ns_container_clone(struct task_struct *tsk, struct nsproxy *nsproxy) { swap_nsproxies(tsk, nsproxy); @@ -52,9 +63,6 @@ int ns_can_attach(struct container_subsy return -EPERM; } - if (atomic_read(&cont->count) != 0) - return -EPERM; - c = task_container(tsk, &ns_subsys); if (c && c != cont->parent) return -EPERM; @@ -90,6 +98,20 @@ void ns_init_from_task(struct container get_nsproxy(ns->nsproxy); } +void ns_attach(struct container_subsys *ss, struct container *cont, + struct container *old_cont, struct task_struct *tsk) +{ + struct nscont *ns = container_nscont(cont); + if (!ns->nsproxy) { + spin_lock(&ns->lock); + if (!ns->nsp…
creator: serue
date: 2007-02-19T22:16:34-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > (Updated patchset addressing Paul's comments. Still looking more > for discussion on functionality, but barring much of that I guess > I'll do something with tsk->fs then send the set to lkml) > > The following patchset uses the ns container subsystem to implement > namespace entering. It applies over the container patchset Paul > sent out earlier today. > Let's describe the problem. There are two usage scenarios. - Working with the parameters of an existing namespace. (For example: changing or reading the hostname of a container you are not in, or setting/reading various resource limits). - Logging in to an existing namespace. I.e. You are the uber sysadmin and the person running a container has a problem or something similar. Until we work through the details of the pid namespace there are going to be details of this we cannot finalize, because we will not have finalized how traditional process groups work. Something more for my todo guess. I have given this some though and I can describe how far we can go without implementing a traditional enter, which is a very long ways. For the general management functions most things already have or can have added a filesystem interface, and we just need to make that filesystem interface per process... That is we can do like what is currently done with /proc/mounts and make /proc/sys a symlink to /proc/self/sys and /proc/<otherpid>/sys can be that other processes view of all of the sysctls. We can do the same thing with /proc/net, and /proc/sysvipc and possibly /sys/net although that is a more difficult. sysfs is a pain to work with. For the actual enter functionality what is currently possible is ugly to implement but extremely close to something useful. You can use sys_ptrace and pick a random process and with a little care cause it to fork and exec the executable of your choice. With these manipulations you can create things like unix domain sockets and pipes and that can be u…
creator: ebiederm
date: 2007-02-20T03:08:45-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > > (Updated patchset addressing Paul's comments. Still looking more > > for discussion on functionality, but barring much of that I guess > > I'll do something with tsk->fs then send the set to lkml) > > > > The following patchset uses the ns container subsystem to implement > > namespace entering. It applies over the container patchset Paul > > sent out earlier today. > > > > Let's describe the problem. There are two usage scenarios. > - Working with the parameters of an existing namespace. > (For example: changing or reading the hostname of a container you are not > in, or setting/reading various resource limits). > - Logging in to an existing namespace. I.e. You are the uber sysadmin > and the person running a container has a problem or something similar. > > Until we work through the details of the pid namespace there are going > to be details of this we cannot finalize, because we will not have finalized > how traditional process groups work. Something more for my todo guess. > > I have given this some though and I can describe how far we can go without > implementing a traditional enter, which is a very long ways. > > > > For the general management functions most things already have or can > have added a filesystem interface, and we just need to make that > filesystem interface per process... > > That is we can do like what is currently done with /proc/mounts and > make /proc/sys a symlink to /proc/self/sys and /proc/<otherpid>/sys > can be that other processes view of all of the sysctls. > > We can do the same thing with /proc/net, and /proc/sysvipc and > possibly /sys/net although that is a more difficult. sysfs is a pain > to work with. > > > > For the actual enter functionality what is currently possible is ugly > to implement but extremely close to something useful. You can use > sys_ptrace and pick a random process and with a little care cause > it to for…
creator: serue
date: 2007-02-20T16:27:08-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> >> You miss an issue here. One of the dangers of enter is leaking >> capabilities into a contained set of processes. Once you show up in > > Good point. As wrong as it feels to me to use ptrace for this, the > advantage is that none of my task attributes leak into the target > namespace, and that's a very good thing. > > I do wonder how you specify what the forced clone should run. > Presumably you want to run something not in the target container. > I suppose we can pass the fd over a socket or something. Yes. At least in the case without a network namespace I can setup a unix domain socket and pass file descriptors around. I think my solution to the network namespace case was to just setup a unix domain socket in the parent namespace and leave it open in init. Not a real solution :( > Herbert, does this sound like it suffices to you? Of course, it does > mean that you cannot switch just a few namespaces. How does that limit > you? > >> /proc processes can change into your working directory which is >> outside of the container for example. > > I suppose I could get into specific ways that this could be prevented > from being exploited, but for now I'll just stick to agreeing that there > would be a whole bunch of issues like this, and we'd likely miss more > than one. Thanks. I think what we want is an API where what is leaked is an explicit decision rather then everything leaking implicitly and the user space programmer has to run around and close all of the holes. >> Yes. This looks to be the most sensible thing and now that we have >> struct pid we don't have to special case anything to implement a >> pid showing up in multiple pid namespaces. So it is my expectation >> that each process will show up in the pid namespace of all of it's >> parents up to init. > > In fact we were thinking there could be an additional clone flag when > doing CLONE_PIDNS to determine…
creator: ebiederm
date: 2007-02-20T17:38:12-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > > Quoting Eric W. Biederman (ebiederm@xmission.com): > >> > >> You miss an issue here. One of the dangers of enter is leaking > >> capabilities into a contained set of processes. Once you show up in > > > > Good point. As wrong as it feels to me to use ptrace for this, the > > advantage is that none of my task attributes leak into the target > > namespace, and that's a very good thing. > > > > I do wonder how you specify what the forced clone should run. > > Presumably you want to run something not in the target container. > > I suppose we can pass the fd over a socket or something. > > Yes. At least in the case without a network namespace I can setup > a unix domain socket and pass file descriptors around. I think my solution > to the network namespace case was to just setup a unix domain socket in > the parent namespace and leave it open in init. Not a real solution :( How about we solve both this and the general ugliness of using ptrace with a new hijack_and_clone(struct task_struct *tsk, int fd) Which takes tsk, clones it, and execs the contents of fd? -serge _______________________________________________ Containers mailing list Containers@lists.osdl.org https://lists.osdl.org/mailman/listinfo/containers
creator: serue
date: 2007-02-21T21:04:01-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > How about we solve both this and the general ugliness of using ptrace > with a new > > hijack_and_clone(struct task_struct *tsk, int fd) > > Which takes tsk, clones it, and execs the contents of fd? That is what roughly what I was thinking. Although that is an ugly beast to implement. Getting stdin and stdout should still be doable using a tty. Getting the semantics and the implementation right is a tough challenge. After thinking about it a normal exec (unless you want your binary to come from inside the namespace) is nearly useless because it requires a static binary. With glibc not actually going static, static binaries are nearly impossible to write. Although that might be a good argument for minimalism, and security. The really important use of the ptrace case is that it works using existing mechanisms without leaks. So it is very useful yardstick. The other important yardstick is arranging it so that when you login to a machine all of the user code runs in your target environment. How you get there is irrelevant. One of the cases I have been worrying about in looking at the semantics of enter is what do you do with the parent pid. Supporting ptrace from outside the pid namespace of a process inside a pid namespace requires supporting a parent process outside of the pid namespace for processes other than init. I'm not convinced setting up a non-ptrace parent that is outside the pid namespace makes sense, but it looks like the mechanism is going to be there. If we did support a foreign parent it would go a long way towards supporting the login and be redirected into a container case, as well as Herbert's pid namespace without an init case. I have finally worked through all of the reasonable irq handling alternatives and unless something goes wrong will I will be submitting that code tomorrow. I really want to pull some pid namespace patches together so we can bring those into the conversation but I don't think I wil…
creator: ebiederm
date: 2007-02-22T08:55:27-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: On 2/22/07, Eric W. Biederman <ebiederm@xmission.com> wrote: > > The really important use of the ptrace case is that it works using > existing mechanisms without leaks. So it is very useful yardstick. > > The other important yardstick is arranging it so that when you login > to a machine all of the user code runs in your target environment. > How you get there is irrelevant. > > One of the cases I have been worrying about in looking at the > semantics of enter is what do you do with the parent pid. Supporting > ptrace from outside the pid namespace of a process inside a pid > namespace requires supporting a parent process outside of the pid > namespace for processes other than init. > When I implemented a virtual server solution at my previous job, we solved the problem of leaking capabilities into the virtualized environment by allowing a process to enter the virtual server in a "privileged" mode, in which it didn't appear in the virtualized /proc, and hence none of its resources were accessible to processes in the VS. Children of a privileged process were by default regular members of the virtual server. With the nsproxy model, maybe you could implement that by having two pid namespaces. When you create the VS, you create an entire set of new namespaces; then before forking init you create a new pid_ns. So by entering the outer nsproxy you'd get access to the same environment that the VS sees, but your process wouldn't be visible to processes in the VS. If you wanted to create a regular process, you'd just enter the inner pid_ns too. I think that doing the appropriate process "sanitization" to avoid leaking capabilities would be easier from the "twilight zone" intermediate nsproxy than from the machine top-level. Paul _______________________________________________ Containers mailing list Containers@lists.osdl.org https://lists.osdl.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-02-22T16:53:10-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: "Paul Menage" <menage@google.com> writes: > When I implemented a virtual server solution at my previous job, we > solved the problem of leaking capabilities into the virtualized > environment by allowing a process to enter the virtual server in a > "privileged" mode, in which it didn't appear in the virtualized /proc, > and hence none of its resources were accessible to processes in the > VS. Children of a privileged process were by default regular members > of the virtual server. > > With the nsproxy model, maybe you could implement that by having two > pid namespaces. When you create the VS, you create an entire set of > new namespaces; then before forking init you create a new pid_ns. So > by entering the outer nsproxy you'd get access to the same environment > that the VS sees, but your process wouldn't be visible to processes in > the VS. If you wanted to create a regular process, you'd just enter > the inner pid_ns too. I think that doing the appropriate process > "sanitization" to avoid leaking capabilities would be easier from the > "twilight zone" intermediate nsproxy than from the machine top-level. And this is why I keep coming back to ptrace. It doesn't leak and it does seem to get the job done. If you have to because you can run system calls you can implement exec by hand. ptrace also allows many of the intermediate enter scenarios. ptrace is clumsy and there does have to be a better way but until I find something that isn't clumsy I will stick with ptrace. Now it is at least worth investigating if you can leak things if you don't enter the pid namespace. If you can not leak things that potentially simplifies big chunks of the problem, and we probably don't need the intermediate pid namespace, of your suggestion. Still I'm drawn back to the simplicity of the proof of the ptrace situation. On another note Serge there is another possibility for dealing with fs_struct. You can chdir(/proc/<someotherpidinthenamespace>/) and get your working directory change…
creator: ebiederm
date: 2007-02-22T20:42:46-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: On 2/22/07, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Now it is at least worth investigating if you can leak things if you don't > enter the pid namespace. If you can not leak things that potentially > simplifies big chunks of the problem, and we probably don't need the > intermediate pid namespace, of your suggestion. If you're happy to have your partially-entered process be viewing the system pid namespace rather than (container pid namespace) + (self) then yes, you don't need the intermediate namespace. Paul _______________________________________________ Containers mailing list Containers@lists.osdl.org https://lists.osdl.org/mailman/listinfo/containers
creator: Paul Menage
date: 2007-02-22T20:49:34-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: On Mon, Feb 19, 2007 at 04:14:46PM -0600, Serge E. Hallyn wrote: > (Updated patchset addressing Paul's comments. Still looking more > for discussion on functionality, but barring much of that I guess > I'll do something with tsk->fs then send the set to lkml) > > The following patchset uses the ns container subsystem to implement > namespace entering. It applies over the container patchset Paul > sent out earlier today. > > = Usage = > > Following is example usage: > > mkdir /container_ns > mount -t container -ons nsproxy /container_ns > (start screen with two windows) > (screen one) > (unshare uts namespace) > hostname serge > (screen two) > hostname > (shows old hostname) > echo $$ > /container_ns/node1/tasks (assuming node1 is screen one's new container) > hostname > (shows 'serge') > > Of course to get a useful result with the mounts namespace, we would > have to convert the fs_struct to a namespace, and the mounts and > fs_struct namespaces would be entered together. > > If we follow this path, the next step would be to add files under > the container directory for each namespace, with ops->link defined > such that you could > > mkdir /container_ns/new_container > ln /container_ns/vserver1/network /container_ns/new_container/network > echo $$ > /container_ns/new_container/tasks > > and be entered into a set of namespaces containing all of your defaults > except network, which would come from vserver1. > > This is RFC not just on implementation, but also on whether to do > it at all. If so, then for all namespace, or only some? And if not, > how to facilitate virtual server management. > > = Security = > > Currently to enter a namespace, you must have CAP_SYS_ADMIN, and must > be entering a container which is an immediate child of your current > container. So from the root container you could enter container /vserver1, > but from container /vserver1 you could not enter /vserver2 or the root > container. > > This may turn out to be sufficient. If not, then LSM ho…
creator: Herbert Poetzl
date: 2007-03-10T01:36:29-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: Herbert Poetzl <herbert@13thfloor.at> writes: > > sorry for the late answer, I almost missed that one ... > > yes, that sounds like an acceptable alternative, but > it might give some interesting issues with references > to devices ... for example: > > you mount a filesystem inside a namespace, so that > only the guest will see it (in theory) now you somehow > show that in the namespace copy too (on the host system) > and if some task decides to go camping there (cd into > that) it might keep the guest from unmounting that > device without ever knowing why ... or do you have some > smart solution to that? lazy unmount. >> net+pid+uts >> >> Not sure about uts, but I'm pretty sure the vserver folks want the >> ability to enter another existing network namespace, and both vserver >> and openvz have asked for the ability to enter pid namespaces. > > yes, definitely, pid and network namespaces have to > be accessible somehow, most administrative work is > done this way, when the administrator also maintains > the guests (i.e. doesn't want to bother accessing the > guest via special console/ssh/logon/whatever) > >> The pid namespaces could be solved by always generating as many pids for >> a process as it has parent pid_namespaces. So if I'm in /vserver1, with >> one pid_namespace above me, not only my init process has an entry in the >> root pid_namespace (as I think has been suggested), but all my children >> will also continue to have pids in the root pid_namespace. > > yep, sounds okay to me ... > note, our lightweight guests do not have an init > process, which is perfectly fine with the above, as > long as the init process is not considered a special > handle to the pid namespace :) > >> Or, if it is ok for the pid namespace operations to be as coarse as >> "kill all processes in /vserver1", then that was going to be implemented >> using the namespace container subsystem as: >> >> rm -rf /container_ns/vserver1 > > that is definitely something you do not want to make…
creator: ebiederm
date: 2007-03-11T19:41:03-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > Herbert Poetzl <herbert@13thfloor.at> writes: > > > > > sorry for the late answer, I almost missed that one ... > > > > yes, that sounds like an acceptable alternative, but > > it might give some interesting issues with references > > to devices ... for example: > > > > you mount a filesystem inside a namespace, so that > > only the guest will see it (in theory) now you somehow > > show that in the namespace copy too (on the host system) > > and if some task decides to go camping there (cd into > > that) it might keep the guest from unmounting that > > device without ever knowing why ... or do you have some > > smart solution to that? > > lazy unmount. > > >> net+pid+uts > >> > >> Not sure about uts, but I'm pretty sure the vserver folks want the > >> ability to enter another existing network namespace, and both vserver > >> and openvz have asked for the ability to enter pid namespaces. > > > > yes, definitely, pid and network namespaces have to > > be accessible somehow, most administrative work is > > done this way, when the administrator also maintains > > the guests (i.e. doesn't want to bother accessing the > > guest via special console/ssh/logon/whatever) > > > >> The pid namespaces could be solved by always generating as many pids for > >> a process as it has parent pid_namespaces. So if I'm in /vserver1, with > >> one pid_namespace above me, not only my init process has an entry in the > >> root pid_namespace (as I think has been suggested), but all my children > >> will also continue to have pids in the root pid_namespace. > > > > yep, sounds okay to me ... > > note, our lightweight guests do not have an init > > process, which is perfectly fine with the above, as > > long as the init process is not considered a special > > handle to the pid namespace :) > > > >> Or, if it is ok for the pid namespace operations to be as coarse as > >> "kill all processes in /vserver1", then that was going to be implemente…
creator: serue
date: 2007-03-12T16:15:30-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: On Sat, 2007-03-10 at 02:36 +0100, Herbert Poetzl wrote: > you mount a filesystem inside a namespace, so that > only the guest will see it (in theory) now you somehow > show that in the namespace copy too (on the host system) > and if some task decides to go camping there (cd into > that) it might keep the guest from unmounting that > device without ever knowing why ... or do you have some > smart solution to that? What is the actual issue here? That an underlying device might still be in use, or that the container user has a directory they don't want mounted sitting in their fs tree? -- Dave _______________________________________________ Containers mailing list Containers@lists.osdl.org https://lists.osdl.org/mailman/listinfo/containers
creator: Dave Hansen
date: 2007-03-12T17:00:34-00:00

Re: [RFC] ns containers (v2): namespace entering
type: item
description: On Mon, Mar 12, 2007 at 10:00:34AM -0700, Dave Hansen wrote: > On Sat, 2007-03-10 at 02:36 +0100, Herbert Poetzl wrote: > > you mount a filesystem inside a namespace, so that > > only the guest will see it (in theory) now you somehow > > show that in the namespace copy too (on the host system) > > and if some task decides to go camping there (cd into > > that) it might keep the guest from unmounting that > > device without ever knowing why ... or do you have some > > smart solution to that? > > What is the actual issue here? > That an underlying device might still be in use, yes, after thinking about it, it might not be such an issue after all, because in 95% of all cases, this is only a problem for the host admin, and can be prevented by simply _not_ doing that ... > or that the container user has a directory they don't want > mounted sitting in their fs tree? that shouldn't actually happen no? if the guest is allowed to do unmounts, then the mount can be removed from inside, if not, then the mount has to be part of the guest configuration, so no problem there IMHO thanks, Herbert > -- Dave _______________________________________________ Containers mailing list Containers@lists.osdl.org https://lists.osdl.org/mailman/listinfo/containers
creator: Herbert Poetzl
date: 2007-03-13T13:16:54-00:00