Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
As it sits right now using the user namespace instead of being an
enhancement of security as it should feels like security loophole
101.
That's a bit of a callous exaggeration, don't you think
Quoting Andrew Morton ([EMAIL PROTECTED]):
On Wed, 24 Jan 2007 12:58:45 -0600
Serge E. Hallyn [EMAIL PROTECTED] wrote:
If we need to I can see doing something special if the process setting
fown has CAP_KILL
Obviously CAP_KILL is insufficient :) I assume you mean a new
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
Quoting Andrew Morton ([EMAIL PROTECTED]):
On Wed, 24 Jan 2007 12:58:45 -0600
Serge E. Hallyn [EMAIL PROTECTED] wrote:
If we need to I can see doing something special if the process setting
fown has CAP_KILL
Obviously CAP_KILL
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
The next steps are (not necessarily in order):
1. allow rm -rf to kill all processes under a
ns_container - with the intent of killing all
processes in a virtual server
2. implement transitioning into a populated
(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
From: Serge E. Hallyn [EMAIL PROTECTED]
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 [EMAIL
From: Serge E. Hallyn [EMAIL PROTECTED]
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
From: Serge E. Hallyn [EMAIL PROTECTED]
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
Quoting Paul Menage ([EMAIL PROTECTED]):
On 2/20/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
All that is necessary to have a group of processes do something
in an unnamed fashion is to hang a pointer off of the task_struct.
That's easy.
Right, adding a pointer to task_struct is easy.
From: Serge E. Hallyn [EMAIL PROTECTED]
Subject: [PATCH] namespaces: update some function names
The {get,exit}_task_namespaces do not grab references to the individual
namespaces, only to the nsproxy. Reflect that in the function names.
Not so important right now, but when pid_ns gets pulled
Quoting Badari Pulavarty ([EMAIL PROTECTED]):
Hi,
sys_clone() and sys_unshare() handles copy/clone of nsproxy
and its associated namespaces differently.
This patch merges all the handling into common functions
(as much as possible).
Please review. If no objections, I would like to
Quoting Paul Menage ([EMAIL PROTECTED]):
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ok, they share this characteristic with namespaces: that they group
processes.
Namespaces have a side effect of grouping processes, but a namespace is
not defined by 'grouping proceses.' A container is,
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
It is good to see these patches are starting to come together.
Be patient a good review is going to take me a little bit.
A couple of immediate things I see that would be nice to address before
we aim at merging these patches upstream.
-
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
[EMAIL PROTECTED] writes:
From: Cedric Le Goater [EMAIL PROTECTED]
Subject: [RFC][PATCH 1/6] Add struct pid_nr
Define struct pid_nr and some helper functions that will be used in
subsequent patches.
Changelog:
- [Serge Hallyn
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations
(by
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Ian Kent [EMAIL PROTECTED] writes:
On Fri, 2007-03-16 at 15:44 +0100, Cedric Le Goater wrote:
How about you send over the autofs4 bit and I'll have a look (the autofs
patch looked fine). That would save me a bit of time and if there are
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Index: 2.6.20/fs/autofs4/waitq.c
===
--- 2.6.20.orig/fs/autofs4/waitq.c
+++ 2.6.20/fs/autofs4/waitq.c
@@ -292,8 +292,8
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Dave Hansen [EMAIL PROTECTED] writes:
On Mon, 2007-03-19 at 20:04 -0600, Eric W. Biederman wrote:
Dave Hansen [EMAIL PROTECTED] writes:
Regardless I would like to see a little farther down on
how we test to see if the pid namespace is alive
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Dave Hansen [EMAIL PROTECTED] writes:
On Mon, 2007-03-19 at 20:04 -0600, Eric W. Biederman wrote:
I would also
like to see how we perform
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Dave Hansen [EMAIL PROTECTED] writes:
On Tue, 2007-03-20 at 09:51 -0600, Eric W. Biederman wrote:
Outlive is the wrong concept. Ideally we want something that will
live as long as there are processes in the pid_ns.
How about they just
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Except that unless we mandate that pid1 in any namespace can't exit, and
put that feature off until later, we can't not address it.
What if we mandate that pid1 is the last process to exit
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
[EMAIL PROTECTED] writes:
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 03/14] use pid_nr in procfs
With containers, a process can have different pid_t values in different
pid namespaces. To ensure we get the correct
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Cedric Le Goater [EMAIL PROTECTED] writes:
what about a kthread that would be spawned when a task is cloned in an
unshared pid namespace ? This is an extra cost in term of tasks.
If you use kernel_thread this can happen. (Die
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
void autofs4_dentry_release(struct dentry *);
extern void autofs4_kill_sb(struct super_block *);
diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
index 9857543..4a9ad9b 100644
--- a/fs
Quoting Ian Kent ([EMAIL PROTECTED]):
On Tue, 2007-03-20 at 16:01 -0600, Eric W. Biederman wrote:
Serge E. Hallyn [EMAIL PROTECTED] writes:
void autofs4_dentry_release(struct dentry *);
extern void autofs4_kill_sb(struct super_block *);
diff --git a/fs/autofs4/waitq.c b/fs
Quoting Dave Hansen ([EMAIL PROTECTED]):
On Thu, 2007-03-22 at 09:33 -0500, Serge E. Hallyn wrote:
I still prefer that we forego that kthread, and just work toward
allowing pid1 to exit. Really I think the crufty /proc/pid handling
is the only reason we were going to punt
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
So is the pid used for anything other than debugging?
In any case, here is a replacement patch which sends the pid number
in the pid_namespace of the process which did the autofs4 mount.
Still
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-03-21 at 21:19 -0500, Serge E. Hallyn wrote:
Quoting Ian Kent ([EMAIL PROTECTED]):
On Tue, 2007-03-20 at 16:01 -0600, Eric W. Biederman wrote:
Serge E. Hallyn [EMAIL PROTECTED] writes:
void autofs4_dentry_release(struct
Quoting Ian Kent ([EMAIL PROTECTED]):
How does this affect getting ids for waitq request packets of other user
space processes triggering mounts? I'm guessing that they would need to
belong to the appropriate namespace for this mechanism to funtion
correctly.
A feature of the pid namespaces
Quoting Herbert Poetzl ([EMAIL PROTECTED]):
On Tue, Mar 20, 2007 at 11:00:57AM -0500, Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Dave Hansen [EMAIL PROTECTED
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Dave Hansen [EMAIL PROTECTED] writes:
So, doesn't that problem go away (or at least move to be umount's duty)
if we completely disconnect those inodes' lifetime from that of any
process or pid namespace?
If the last process has exited the
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Sat, Mar 24, 2007 at 10:35:37AM +0530, Srivatsa Vaddagiri wrote:
+static int ns_create(struct container_subsys *ss, struct container *cont)
+{
+ struct nscont *ns;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
+/*
+ * Rules: you can only create a container if
+ * 1. you are capable(CAP_SYS_ADMIN)
+ * 2. the target container is a descendant of your own container
+ */
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
This is just to vent.
I was clearly not auditing patches well enough earlier and the above
patch got modified since the version I wrote initially. Adding a
few addition is_init calls where
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Where the latter is needed in, for instance, kernel/capability.c.
Yes.
I think more clear cut examples could be made. It isn't clear to me
why we skip pid == 1 in kernel/capability.c
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
+int ns_container_clone(struct task_struct *tsk)
+{
+ return container_clone(tsk, ns_subsys);
+}
This function is a no-op if ns hierarchy is not mounted at this point.
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Srivatsa Vaddagiri [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
Losing the directory isn't a big deal though. And both unsharing a
namespace (which causes a ns_container_clone) and mounting
Quoting Paul Menage ([EMAIL PROTECTED]):
On 4/3/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
But frankly I don't know where we stand right now wrt the containers
patches. Do most people want to go with Vatsa's latest version moving
containers into nsproxy? Has any other development been
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
This patchset adds support for keeping mount ownership information in
the kernel, and allow unprivileged mount(2) and umount(2) in certain
cases.
No replies, huh?
All we need is a comment from Andrew, and the replies come flooding in ;)
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
One thing that is missing from this series is the ability to restrict
user mounts to private namespaces. The reason is that private
namespaces have still not gained the momentum and support needed for
painless user experience. So
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Dave Hansen [EMAIL PROTECTED] writes:
I've been hacking quite a bit on the pidspace code. I've run
into a bug or two, and had a heck of a time debugging it.
Other than my inferior puny monkey brain, I'm directing some
of the blame squarely
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of allowing
Quoting Kirill Korotaev ([EMAIL PROTECTED]):
Kirill,
We are working on getting a few UTS namespace tests included in Linux
Testsuite Project (LTP) and were wondering if you (or anyone else) had
any test cases for IPC namespace.
If there are tests for IPC NS, can you share those
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
unshare(2), then allow user mounts within the new namespace.
This is not flexible enough, because user mounts can't be enabled for
the initial
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
move
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Given the existence of shared subtrees allowing/denying this at the mount
namespace level is silly and wrong.
If we need more than just the filesystem permission checks can we
make it a mount flag settable with mount and remount that allows
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a bunch of mounts
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Agreed on desired behavior, but not on chroot sufficing. It actually
sounds like you want exactly what was outlined in the OLS paper.
Users still need to be in a different mounts namespace from the admin
user so long as we consider
Quoting Ram Pai ([EMAIL PROTECTED]):
On Mon, 2007-04-16 at 12:34 +0200, Miklos Szeredi wrote:
Currently one of the difficulties with mount propagations is that
there's no way to know the current state of the propagation tree.
Has anyone thought about how this info could be queried from
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
-serge
unprivileged mounts will
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Miklos Szeredi [EMAIL PROTECTED] writes:
That depends. Current patches check the unprivileged submounts
allowed under this mount flag only on the requested mount and not on
the propagated mounts. Do you see a problem with this?
I
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Why are directory permissions not sufficient to allow/deny non-priveleged
mounts?
I don't understand that contention yet.
The same scenarios laid out previously in this thread. I.e.
1. user
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser more clear than usermnt? What is allowed to the
I think so, yes. One makes it clear that we're
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Why are directory permissions not sufficient to allow/deny non-priveleged
mounts?
I don't understand that contention yet.
The same scenarios laid out previously in this thread. I.e.
1. user
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
This patchset has now been bared to the lowest common denominator
that everybody can agree on. Or at least there weren't any objections
to this proposal.
Andrew, please consider it for -mm.
Thanks,
Miklos
v3 - v4:
- simplify
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Miklos Szeredi [EMAIL PROTECTED] writes:
From: Miklos Szeredi [EMAIL PROTECTED]
- refine adding nosuid and nodev flags for unprivileged mounts:
o add nosuid, only if mounter doesn't have CAP_SETUID capability
o add nodev, only if
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
Miklos Szeredi wrote:
Andrew, please skip this patch, for now.
Serge found a problem with the fsuid approach: setfsuid(nonzero) will
remove
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Are there other permission checks that mount is doing that we
care about.
Not mount itself, but in looking up /share/fa/root/home/fa,
user fa
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Right, I figure if the normal action is to always do
mnt-user = current-fsuid, then for the special case we
pass a uid in someplace. Of course... do we not have a
place to do that? Would it
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
So then as far as you're concerned, the patches which were in -mm will
remain unchanged?
Basically yes. I've merged the update patch, which was not yet added
to -mm, did some cosmetic code changes, and updated the patch headers.
There's one
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
The set of functions process_session, task_session, process_group
and task_pgrp is confusing, as the names can be mixed with each other
when looking at the code for a long time.
The proposals are to
* equip the functions that return the integer
Quoting Alexey Dobriyan ([EMAIL PROTECTED]):
I ran ltp-full-20070430 and utstest.c forgot to restore original
hostname from serge2. ;-)
Oh that's just me taking over the world, one workstation at a time.
Hopefully this simple obvious silly workaround fixes it?
It should also fix 'make no_ltp'
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Subject: Enable signaling child reaper from parent ns.
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
The reaper of a child namespace must receive signals from its parent pid
namespace but not receive any signals from its own namespace.
they are only used with the explicit task-signal dereference.
I've sent this before, but Andrew didn't include it, so I resend it
as the part of this set.
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
Acked-by: Serge E. Hallyn [EMAIL PROTECTED]
Yup, I still like this patch.
thanks
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
That's how OpenVZ sees the pid namespaces.
The main idea is that kernel keeps operating with tasks pid
as it did before, but each task obtains one more pid for each
pid
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
3. Cleaner logic for namespace migration: with this approach
one need to save the virtual pid and let global one change
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
The set of functions process_session, task_session, process_group
and task_pgrp
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Pavel Emelianov [EMAIL PROTECTED] writes:
That's how OpenVZ sees the pid namespaces.
The main idea is that kernel keeps operating with tasks pid
as it did before
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
3. Cleaner logic for namespace migration: with this approach
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
This includes #ifdefs in get/put_pid_ns and rewriting
the child_reaper() function to the more logical view
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Subject: Enable signaling child reaper from parent ns.
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
The reaper of a child namespace must receive signals from its parent pid
namespace but not receive any signals from its own namespace.
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Dave Hansen wrote:
On Tue, 2007-05-29 at 15:45 +0400, Pavel Emelianov wrote:
The detailed results are the following:
Test name:spawn execlshellps (sys time)
1(no ns) :579.1 618.31623.2 3.052s
2(suka's):570.7
Quoting Andrew Morton ([EMAIL PROTECTED]):
On Tue, 29 May 2007 06:01:09 -0700 [EMAIL PROTECTED] wrote:
This patch adds support for container_clone(), a speculative interface
to creating new containers intended to be used for systems such as
namespace unsharing.
...
+
+static
Quoting Andrew Morton ([EMAIL PROTECTED]):
On Fri, 1 Jun 2007 16:48:09 -0500
Serge E. Hallyn [EMAIL PROTECTED] wrote:
This compiles and boots, but is not intended for inclusion in -mm (yet),
just as an RFC for the naming scheme to fix the bug Andrew pointed out.
Seem ok overall
Again, not compiles and boots, but not sufficiently tested for
inclusion.
thanks,
-serge
From 6c03518dbda04bf20a9ddeefb291bf1c63e32ec1 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Fri, 1 Jun 2007 17:30:16 -0400
Subject: [PATCH 2/2] Container interface to nsproxy
Sorry, didn't paste in my comment at the top that this is again not at
all for inclusion, and barely tested, but mainly to get comment i.e. on
the way the naming is done.
thanks,
-serge
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00
From nobody Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 17:17:23 -0400
Subject: [PATCH 4/6] user ns: hook generic_permission()
Hook generic_permission() to check for user namespaces.
Also define task_ino_capable() which denies a capability
if the subject
From nobody Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 13:00:47 -0400
Subject: [PATCH 2/6] user namespace : add unshare
Changelog: Fix !CONFIG_USER_NS clone with CLONE_NEWUSER so it returns -EINVAL
rather than 0, so that userspace knows
Hi Paul,
I've got two problems working with this patchset:
1. A task can't join a cpuset unless 'cpus' and 'mems' are set. These
don't seem to automatically inherit the parent's values. So when I do
mount -t container -o ns,cpuset nsproxy /containers
(unshare a namespace)
the
From nobody Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Wed, 28 Mar 2007 13:11:19 -0500
Subject: [PATCH 6/6] userns strict: hook ext3
Add a user namespace pointer to the ext3 superblock and inode.
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
---
fs/ext3/acl.c
From nobody Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 14:02:09 -0400
Subject: [PATCH 3/6] user ns: add an inode user_ns pointer
Add a user namespace pointer to each inode. One user namespace is said
to own each inode. Each filesystem can fill
[ I've been sitting on this for some months, and am just dumping it so
people can talk if they like, maybe even build on the patchset by
adding support for more filesystems or implementing the keyring. Or
tell me how much the approach sucks. ]
First, I point out once more that the base user
struct user_namespace* argument from find_user()
Changes since [try #1]:
- removed struct user_namespace* argument from find_user()
- added a root_user per user namespace
Signed-off-by: Cedric Le Goater [EMAIL PROTECTED]
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
Cc
From nobody Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Wed, 28 Mar 2007 15:06:47 -0500
Subject: [PATCH 5/6] userns strict: hook ext2
Add a user namespace pointer to the ext2 superblock and inode.
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
---
fs/ext2/acl.c
Quoting Paul Menage ([EMAIL PROTECTED]):
On 6/4/07, Paul Jackson [EMAIL PROTECTED] wrote:
Yup - early in the life of cpusets, a created cpuset inherited the cpus
and mems of its parent. But that broke the exclusive property big
time. You will recall that a cpu_exclusive or mem_exclusive
Quoting Paul Menage ([EMAIL PROTECTED]):
On 6/4/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] root]# rm -rf /containers/1
Just use rmdir /containers/1 here.
Hmm. Ok, that works... Odd, I thought rm -rf used to work in the past,
but i'm likely wrong.
thanks,
-serge
Ah, I
Quoting Paul Menage ([EMAIL PROTECTED]):
On 6/4/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
2. I can't delete containers because of the files they contain, and
am not allowed to delete those files by hand.
You should be able to delete a container with rmdir as long as it's
not in use
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:18:52 -0400
Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem
Last year we all met for breakfast at OLS. Now we've all pretty much
all already met so maybe it's less exciting, but do people (who will be
at OLS) care to meet for breakfast on the thursday or friday?
-serge
___
Containers mailing list
[EMAIL
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:18:52 -0400
at checkpoint time.
Have you checked net-dev archives for discussions about not hashing
these inodes? I suppose at some point you'll want to ask there what the
preference is.
But certainly for now this seems the right approach.
Signed-off-by: Daniel Lezcano [EMAIL PROTECTED]
Acked-by: Serge E. Hallyn
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
Mark Pflueger wrote:
hi everyone!
i'm not subscribed to the list, so if you care to flame because of my noob
question, just do it to the list, otherwise please cc me.
you should subscribe to [EMAIL PROTECTED] and send your ideas on that
Quoting Paul Jackson ([EMAIL PROTECTED]):
Would it then make sense to just
default to (parent_set - sibling_exclusive_set) for a new sibling's
value?
Which could well be empty, which in turn puts one back in the position
of dealing with a newborn cpuset that is empty (of cpus or of
Quoting Paul Jackson ([EMAIL PROTECTED]):
I wasn't paying close enough attention to understand why you couldn't
do it in two steps - make the container, and then populate it with
resources.
Sorry, please clarify - are you saying that now you do understand, or
that I should explain?
than
just this.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
thanks,
-serge
From 821de58b6ba446e50225606e907baac00130586c Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn
Quoting Paul Jackson ([EMAIL PROTECTED]):
For /cpusets/set0/set1 to have cpu 1 exclusively, does /cpusets/set0
also have to have it exclusively?
Yes.
If so, then clearly this approach won't work, since if any container has
exclusive cpus, then every container will have siblings with
Quoting Kirill Korotaev ([EMAIL PROTECTED]):
My apologies, but I won't be able to visit OLS this year :/
I think Kirill Kolyshkin and Denis Lunev will be glad to meet you again!
Hope Pavel Emelianov will be able to join as well.
I take it based on Cedric's culinary requirements we should not
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Cedric Le Goater wrote:
Pavel Emelianov wrote:
Cedric Le Goater wrote:
Pavel Emelianov wrote:
[snip]
Did I miss something in the design or this patch worth merging?
I've sent a more brutal patch in the past removing CONFIG_IPC_NS
and
1 - 100 of 1965 matches
Mail list logo
