* Eric W. Biederman ebied...@xmission.com schrieb:
At least for the network namespace there is a lot of value in being
able to just change that single namespace. Having multiple logical
network stacks has it's challenges but has a lot of practical
applications. Especially when there is the
+static struct inode *nsfd_mkinode(void)
+{
+ struct inode *inode;
+ inode = new_inode(nsfd_mnt-mnt_sb);
+ if (!inode)
+ return ERR_PTR(-ENOMEM);
+
+ inode-i_fop = nsfd_file_operations;
+
+ /*
+ * Mark the inode dirty from the very beginning,
+
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't we have an ability to enter them all with one syscall?
The CLONE_NEWXXX series of bits has been an royal pain to work with,
and it appears
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't we have an ability to enter them all with one syscall?
The CLONE_NEWXXX
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't
I agree with all the points you and Pavel you talked about but I don't
feel comfortable to have the current process to switch the pid namespace
because of the process tree hierarchy (what will be the parent of the
process when you enter the pid namespace for example).
The answer is - the
I just played with this and if you make the semantics of unshare(CLONE_NEWPID)
to be that you become the idle task aka pid 0, and not the init task pid 1 the
implementation is trivial.
This is not ... handy - if after enter you have pid 0 you obviously
can't perform 2 parallel enters. The way
2 parallel enters? I meant you have pid 0 in the entered pid namespace.
You have pid 0 because your pid simply does not map.
Oh, I see.
There is nothing that makes to parallel enters impossible in that.
Even today we have one thread per cpu that has task-pid == init_struct_pid
which is pid
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
[ ... ]
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as well.
Eric,
at this point I did not fall in any
Eric W. Biederman wrote:
[ ... ]
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as well.
#include unistd.h
#include stdlib.h
#include stdio.h
#include syscall.h
#include sys/types.h
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
[ ... ]
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as well.
#include unistd.h
#include stdlib.h
#include
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
[ ... ]
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as well.
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
I am going to explore a bit more. Given that nsfd is using the same
permission checks as a proc file, I think I can just make it a proc
file.
Eric W. Biederman wrote:
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
Hi Eric,
thanks for the pointer.
I tried to boot the kernel under qemu and I got this oops:
Loading
Quoting Eric W. Biederman (ebied...@xmission.com):
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
I am going to explore a bit more. Given that nsfd is using the same
permission checks as
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
Hi Eric,
thanks for the pointer.
I tried to boot the kernel under qemu
Serge E. Hallyn se...@us.ibm.com writes:
Quoting Eric W. Biederman (ebied...@xmission.com):
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
I am going to explore a bit more. Given that
Quoting Eric W. Biederman (ebied...@xmission.com):
Serge E. Hallyn se...@us.ibm.com writes:
Quoting Eric W. Biederman (ebied...@xmission.com):
I have take an snapshot of my development tree and placed it at.
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
I have take an snapshot of my development tree and placed it at.
git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
Hi Eric,
thanks for the
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
I have take an snapshot of my development tree and placed it at.
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
I have take an snapshot of my development tree and placed it at.
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
I have take an snapshot of my development
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W.
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr
Quoting Eric W. Biederman (ebied...@xmission.com):
Daniel Lezcano daniel.lezc...@free.fr writes:
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as well.
I'm not certain about the
Serge E. Hallyn se...@us.ibm.com writes:
Quoting Eric W. Biederman (ebied...@xmission.com):
Daniel Lezcano daniel.lezc...@free.fr writes:
I guess my meaning is I was expecting.
child = fork();
if (child == 0) {
execve(...);
}
waitpid(child);
This puts /bin/sh in the container as
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
2 parallel enters? I meant you have pid 0 in the entered pid namespace.
You have pid 0 because your pid simply does not map.
Oh, I see.
There is nothing that makes to parallel enters impossible in that.
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
If the normal rules of parentage apply, that means pid 0 has to wait it's
child.
If we are in the scenario of pid 0, it's child pid 1234 and we kill the pid 1
of
the pid namespace, I suppose pid 1234 will be killed
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
If the normal rules of parentage apply, that means pid 0 has to wait it's
child.
If we are in the scenario of pid 0, it's child pid 1234 and we kill the pid
1 of
the pid
Pavel Emelyanov xe...@parallels.com writes:
2 parallel enters? I meant you have pid 0 in the entered pid namespace.
You have pid 0 because your pid simply does not map.
Oh, I see.
There is nothing that makes to parallel enters impossible in that.
Even today we have one thread per cpu that
ebied...@xmission.com (Eric W. Biederman) writes:
Serge E. Hallyn se...@us.ibm.com writes:
Quoting Eric W. Biederman (ebied...@xmission.com):
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
Eric W. Biederman [ebied...@xmission.com] wrote:
|
| I think replacing a struct pid for
On Thursday 2010-03-04 22:45, Eric W. Biederman wrote:
So an unshare of the pid namespace that doesn't really take effect
until we fork may actually be usable from pam, and in fact is probably
the preferred implementation. It looks like neither openssh nor login
from util-linux-ng will cope
Quoting Eric W. Biederman (ebied...@xmission.com):
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
Eric W. Biederman [ebied...@xmission.com] wrote:
|
| I think replacing a struct pid for another struct pid allocated in
| descendant pid_namespace (but has all of the same struct
Serge E. Hallyn se...@us.ibm.com writes:
Quoting Eric W. Biederman (ebied...@xmission.com):
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
Eric W. Biederman [ebied...@xmission.com] wrote:
|
| I think replacing a struct pid for another struct pid allocated in
| descendant
Quick question:
+void set_namespace(unsigned long nstype, void *ns)
+{
+ struct task_struct *tsk = current;
+ struct nsproxy *new_nsproxy;
+
+ new_nsproxy = create_new_namespaces(0, tsk, tsk-fs);
+ switch(nstype) {
+ case NSTYPE_NET:
+
Jonathan Corbet cor...@lwn.net writes:
Quick question:
+void set_namespace(unsigned long nstype, void *ns)
+{
+struct task_struct *tsk = current;
+struct nsproxy *new_nsproxy;
+
+new_nsproxy = create_new_namespaces(0, tsk, tsk-fs);
+switch(nstype) {
+case NSTYPE_NET:
Daniel Lezcano wrote:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Thanks. What's the problem with setns?
joining a
On 03/01/2010 10:42 PM, Eric W. Biederman wrote:
I am of two mind about my patches. Right now they are a brilliant
proof of concept that we can name namespaces without needing a
namespace for the names of namespaces, and start to be a practical
solution to the join problem. At the same
On Tuesday 2010-03-02 16:03, Pavel Emelyanov wrote:
I agree with all the points you and Pavel you talked about but I don't
feel comfortable to have the current process to switch the pid namespace
because of the process tree hierarchy (what will be the parent of the
process when you enter
Pavel Emelyanov [xe...@parallels.com] wrote:
| I agree with all the points you and Pavel you talked about but I don't
| feel comfortable to have the current process to switch the pid namespace
| because of the process tree hierarchy (what will be the parent of the
| process when you enter
Jan Engelhardt jeng...@medozas.de writes:
On Tuesday 2010-03-02 16:03, Pavel Emelyanov wrote:
I agree with all the points you and Pavel you talked about but I don't
feel comfortable to have the current process to switch the pid namespace
because of the process tree hierarchy (what will be
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
Pavel Emelyanov [xe...@parallels.com] wrote:
| I agree with all the points you and Pavel you talked about but I don't
| feel comfortable to have the current process to switch the pid namespace
| because of the process tree hierarchy
Eric W. Biederman [ebied...@xmission.com] wrote:
|
| I think replacing a struct pid for another struct pid allocated in
| descendant pid_namespace (but has all of the same struct upid values
| as the first struct pid) is a disastrous idea. It destroys the
True. Sorry, I did not mean we would
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
Eric W. Biederman [ebied...@xmission.com] wrote:
|
| I think replacing a struct pid for another struct pid allocated in
| descendant pid_namespace (but has all of the same struct upid values
| as the first struct pid) is a disastrous
Daniel Lezcano daniel.lezc...@free.fr writes:
Replacing struct pid is guaranteed to do all kinds of nasty things with
signal handling and the like, de_thread is nasty enough and you are talking
something worse. So if we can change pid namespaces without changing
the pid I am for it.
I
Daniel Lezcano daniel.lezc...@free.fr writes:
I agree with all the points you and Pavel you talked about but I don't feel
comfortable to have the current process to switch the pid namespace because of
the process tree hierarchy (what will be the parent of the process when you
enter the pid
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Thanks. What's the problem with setns?
joining a preexisting namespace is
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't we have an ability to
Pavel Emelyanov xe...@parallels.com writes:
Thanks. What's the problem with setns?
joining a preexisting namespace is roughly the same problem as
unsharing a namespace. We simply haven't figure out how to do it
safely for the pid and the uid namespaces.
I have designed these file descriptors
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Thanks. What's the problem with setns?
joining a preexisting namespace is roughly the same problem as
unsharing a namespace. We simply haven't figure out how to do it
safely
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Thanks. What's the problem with setns?
joining a preexisting namespace is roughly the same problem as
No, the plan is only one namespace at a time.
Looking at this a bit more I am frustrated and relieved.
I was looking at what it would take to join an arbitrary mount
namespace and I realized it is completely non-obvious what fs-root
and fs-pwd should be set to.
If I leave them untouched the
Pavel Emelyanov xe...@parallels.com writes:
+static struct inode *nsfd_mkinode(void)
+{
+struct inode *inode;
+inode = new_inode(nsfd_mnt-mnt_sb);
+if (!inode)
+return ERR_PTR(-ENOMEM);
+
+inode-i_fop = nsfd_file_operations;
+
+/*
+ * Mark the inode
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't we have an ability to enter them all with one syscall?
The CLONE_NEWXXX series of bits has been
Pavel Emelyanov xe...@parallels.com writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
+static struct inode *nsfd_mkinode(void)
+{
+ struct inode *inode;
+ inode = new_inode(nsfd_mnt-mnt_sb);
+ if (!inode)
+ return ERR_PTR(-ENOMEM);
+
+
Oren Laadan or...@cs.columbia.edu writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't we have an ability to enter
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't we have an ability to enter them all with one syscall?
The
Eric W. Biederman wrote:
Oren Laadan or...@cs.columbia.edu writes:
Eric W. Biederman wrote:
Pavel Emelyanov xe...@parallels.com writes:
Yet another set of per-namespace IDs along with CLONE_NEWXXX ones?
I currently have a way to create all namespaces we have with one
syscall. Why don't
Oren Laadan or...@cs.columbia.edu writes:
Can't think of a specific scenario, but I wonder if there would
be a problem (security or otherwise) with a process that only
partly belongs to a container, even if for a short time ?
If we can find an instance of that then there are fundamental
Eric W. Biederman wrote:
Introduce two new system calls:
int nsfd(pid_t pid, unsigned long nstype);
int setns(unsigned long nstype, int fd);
These two new system calls address three specific problems that can
make namespaces hard to work with.
- Namespaces require a dedicated process to pin
On Thu, Feb 25, 2010 at 12:57:02PM -0800, Eric W. Biederman wrote:
Introduce two new system calls:
int nsfd(pid_t pid, unsigned long nstype);
int setns(unsigned long nstype, int fd);
These two new system calls address three specific problems that can
make namespaces hard to work with.
-
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Introduce two new system calls:
int nsfd(pid_t pid, unsigned long nstype);
int setns(unsigned long nstype, int fd);
These two new system calls address three specific problems that can
make namespaces hard to work with.
Eric W. Biederman wrote:
Daniel Lezcano daniel.lezc...@free.fr writes:
Eric W. Biederman wrote:
Introduce two new system calls:
int nsfd(pid_t pid, unsigned long nstype);
int setns(unsigned long nstype, int fd);
These two new system calls address three specific problems that can
Matt Helsley matth...@us.ibm.com writes:
Seems like an ok concept to me. Did you try doing this with
anon_inodes and bind mounting the /proc/pid/fd/N as above to keep
them alive and name them?
I used a normal file. anon_nodes strictly speaking might work, but they
keep their state in
Daniel Lezcano daniel.lezc...@free.fr writes:
No, the plan is only one namespace at a time.
It would not be much of a change to support multiple namespaces,
but I don't think I want to go there. Bitmaps filling up are
ugly and I don't see what would be gained.
The idea I had in mind
On Thu, Feb 25, 2010 at 12:57:02PM -0800, Eric W. Biederman wrote:
Introduce two new system calls:
int nsfd(pid_t pid, unsigned long nstype);
int setns(unsigned long nstype, int fd);
These two new system calls address three specific problems that can
make namespaces hard to work with.
-
Matt Helsley matth...@us.ibm.com writes:
On Thu, Feb 25, 2010 at 12:57:02PM -0800, Eric W. Biederman wrote:
Introduce two new system calls:
int nsfd(pid_t pid, unsigned long nstype);
int setns(unsigned long nstype, int fd);
These two new system calls address three specific problems that
67 matches
Mail list logo
