OpenVZ Forum - RDF feed
type: channel
items: user namespace - introduction
items: [PATCH 1/6] user namespace : add the framework
items: [PATCH 5/6] userns strict: hook ext2
items: Re: [PATCH 5/6] userns strict: hook ext2
items: Re: [PATCH 1/6] user namespace : add the framework

user namespace - introduction
type: item
description: [ 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 namespace patchset Cedric originally sent out really is sufficient. We just need for users to have different quotas, limits, and in-kernel key storage. Signal delivery, file controls, etc can be set up using pidspaces and separate mount trees, using selinux policy or other lsms, and even using ecryptfs. But if it will be insisted upon that uid checks be enhanced, here is a new patchset which just might satisfy everyone, and which is based on user namespace discussions from the last year, particularly comments by Eric Biederman and David Howells. Below is how I think the user namespace controls would work. The patches that follow only touch on parts of steps 1-4. 1. let filesystem tag inodes and superblocks with one user namespace 2. let generic_permission - and through inode->i_op->permission, the fs, if it wants to be smarter - enforce user namespaces 3. by default, inode->i_userns comes from sb->s_userns, just as is done in these patches. 4. By default, if inode->i_userns != task->userns, the process gets treated as 'nobody'. This is a change from my current patches and what is done in -lxc, where all permission is denied. I think it is a far preferable behavior. It allows read-only bind mount sharing among user namespaces without a silly MS_USER_NS flag. 5. Capabilities relating to actions on subjects or objects associated with a user namespace are only effective for targets in the same user namespace as the actor. This *could* be changed to also work for targets in decendant user namespaces, but that could slow things down. 6. Create a new keychain for user namespaces. Two types of entries. The first type of entry, (user_ns 5, uid 501) means that whichever user has that key w…
creator: serue
date: 2007-06-04T19:39:57-00:00

[PATCH 1/6] user namespace : add the framework
type: item
description: >From nobody Mon Sep 17 00:00:00 2001 From: Cedric Le Goater <clg@fr.ibm.com> Date: Thu, 5 Apr 2007 12:51:51 -0400 Subject: [PATCH 1/6] user namespace : add the framework Add the user namespace struct and framework Basically, it will allow a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting. A new root user (uid == 0) is added to the user namespace upon creation. Such root users have full privileges and it seems that theses privileges should be controlled through some means (process capabilities ?) The unshare is not included in this patch. Changes since [try #4]: - Updated get_user_ns and put_user_ns to accept NULL, and get_user_ns to return the namespace. Changes since [try #3]: - moved struct user_namespace to files user_namespace.{c,h} Changes since [try #2]: - removed 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 <clg@fr.ibm.com> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> Cc: Herbert Poetzl <herbert@13thfloor.at> Cc: Kirill Korotaev <dev@sw.ru> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- include/linux/init_task.h | 2 + include/linux/nsproxy.h | 1 + include/linux/sched.h | 3 +- include/linux/user_namespace.h | 57 ++++++++++++++++++++++++++++++++++++++++ init/Kconfig | 9 ++++++ kernel/Makefile | 2 + kernel/fork.c | 2 + kernel/nsproxy.c | 10 +++++++ kernel/sys.c | 5 ++-- kernel/user.c | 18 ++++++------- kernel/user_namespace.c | 43 ++++++++++++++++++++++++++++++ 11 files changed, 138 insertions(+), 14 deletions(-) create mode 100644 include/linux/user_namespace.h create mode 100644 kernel/user_namespace.c cfeebe74a11622089791ecb14070f4d620f55535 diff --git a/include/linux/init_task.h b/include/linux/init_task.h index cca7bb1..1fdc…
creator: serue
date: 2007-06-04T19:40:24-00:00

[PATCH 5/6] userns strict: hook ext2
type: item
description: >From nobody Mon Sep 17 00:00:00 2001 From: Serge Hallyn <serue@us.ibm.com> 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 <serue@us.ibm.com> --- fs/ext2/acl.c | 4 +++- fs/ext2/balloc.c | 13 ++++++++++--- fs/ext2/ialloc.c | 5 +++++ fs/ext2/inode.c | 2 ++ fs/ext2/ioctl.c | 12 ++++++++---- fs/ext2/super.c | 4 ++++ fs/ext2/xattr_trusted.c | 3 ++- include/linux/ext2_fs_sb.h | 1 + include/linux/user_namespace.h | 16 ++++++++++++++++ 9 files changed, 51 insertions(+), 9 deletions(-) 04b91190fbcaf388100bc748062724e384f1d868 diff --git a/fs/ext2/acl.c b/fs/ext2/acl.c index 7c420b8..7bb1ccd 100644 --- a/fs/ext2/acl.c +++ b/fs/ext2/acl.c @@ -9,6 +9,7 @@ #include <linux/init.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/fs.h> +#include <linux/user_namespace.h> #include "ext2.h" #include "xattr.h" #include "acl.h" @@ -464,7 +465,8 @@ ext2_xattr_set_acl(struct inode *inode, if (!test_opt(inode->i_sb, POSIX_ACL)) return -EOPNOTSUPP; - if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER)) + if (!task_inode_same_fsuid(current, inode) && + !task_ino_capable(inode, CAP_FOWNER)) return -EPERM; if (value) { diff --git a/fs/ext2/balloc.c b/fs/ext2/balloc.c index 538c221..2924f0e 100644 --- a/fs/ext2/balloc.c +++ b/fs/ext2/balloc.c @@ -16,6 +16,7 @@ #include <linux/quotaops.h> #include <linux/sched.h> #include <linux/buffer_head.h> #include <linux/capability.h> +#include <linux/user_namespace.h> /* * balloc.c contains the blocks allocation and deallocation routines @@ -1127,9 +1128,15 @@ static int ext2_has_free_blocks(struct e free_blocks = percpu_counter_read_positive(&sbi->s_freeblocks_counter); root_blocks = le32_to_cpu(sbi->s_es->s_r_blocks_count); - if (free_blocks < root_blocks + 1 && !capable(CAP_SYS_RESOURCE) && - sbi->s_resuid != current->fsuid && - (sbi->s_resgid == 0 || !in_group_p (sbi->s_resgid))) { + if (free_block…
creator: serue
date: 2007-06-04T19:42:00-00:00

Re: [PATCH 5/6] userns strict: hook ext2
type: item
description: Serge E. Hallyn wrote: >>From nobody Mon Sep 17 00:00:00 2001 > From: Serge Hallyn <serue@us.ibm.com> > 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 <serue@us.ibm.com> > > --- > > fs/ext2/acl.c | 4 +++- > fs/ext2/balloc.c | 13 ++++++++++--- > fs/ext2/ialloc.c | 5 +++++ > fs/ext2/inode.c | 2 ++ > fs/ext2/ioctl.c | 12 ++++++++---- > fs/ext2/super.c | 4 ++++ > fs/ext2/xattr_trusted.c | 3 ++- > include/linux/ext2_fs_sb.h | 1 + > include/linux/user_namespace.h | 16 ++++++++++++++++ > 9 files changed, 51 insertions(+), 9 deletions(-) > [snip] > diff --git a/fs/ext2/ialloc.c b/fs/ext2/ialloc.c > index 86a2f3b..34f16ab 100644 > --- a/fs/ext2/ialloc.c > +++ b/fs/ext2/ialloc.c > @@ -17,6 +17,7 @@ #include <linux/sched.h> > #include <linux/backing-dev.h> > #include <linux/buffer_head.h> > #include <linux/random.h> > +#include <linux/user_namespace.h> > #include "ext2.h" > #include "xattr.h" > #include "acl.h" > @@ -133,6 +134,9 @@ void ext2_free_inode (struct inode * ino > /* Do this BEFORE marking the inode not in use or returning an error */ > clear_inode (inode); > > + put_user_ns(inode->i_userns); > + inode->i_userns = NULL; > + > if (ino < EXT2_FIRST_INO(sb) || > ino > le32_to_cpu(es->s_inodes_count)) { > ext2_error (sb, "ext2_free_inode", > @@ -563,6 +567,7 @@ got: > sb->s_dirt = 1; > mark_buffer_dirty(bh2); > inode->i_uid = current->fsuid; > + inode->i_userns = get_task_user_ns(current); We have all the ext2 (and in the next patch - the ext3) inodes attached to a particular user and prohibit access to the inodes belonging to other tasks' namespaces, don't we? If so how can we allow the admin of the node to configure the root of a virtual server on the fly? [snip] > diff --git a/fs/ext2/super.c b/fs/ext2/super.c > index 932579b..75ce9e8 100644 > --- a/fs/ext2/super.c > +++ b/fs/ext2/super.c > @@ -29,6 +29,7 @@ #include <linux/smp_…
creator: xemul
date: 2007-06-05T10:16:37-00:00

Re: [PATCH 5/6] userns strict: hook ext2
type: item
description: Quoting Pavel Emelianov (xemul@sw.ru): > Serge E. Hallyn wrote: > >>From nobody Mon Sep 17 00:00:00 2001 > > From: Serge Hallyn <serue@us.ibm.com> > > 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 <serue@us.ibm.com> > > > > --- > > > > fs/ext2/acl.c | 4 +++- > > fs/ext2/balloc.c | 13 ++++++++++--- > > fs/ext2/ialloc.c | 5 +++++ > > fs/ext2/inode.c | 2 ++ > > fs/ext2/ioctl.c | 12 ++++++++---- > > fs/ext2/super.c | 4 ++++ > > fs/ext2/xattr_trusted.c | 3 ++- > > include/linux/ext2_fs_sb.h | 1 + > > include/linux/user_namespace.h | 16 ++++++++++++++++ > > 9 files changed, 51 insertions(+), 9 deletions(-) > > > > [snip] > > > diff --git a/fs/ext2/ialloc.c b/fs/ext2/ialloc.c > > index 86a2f3b..34f16ab 100644 > > --- a/fs/ext2/ialloc.c > > +++ b/fs/ext2/ialloc.c > > @@ -17,6 +17,7 @@ #include <linux/sched.h> > > #include <linux/backing-dev.h> > > #include <linux/buffer_head.h> > > #include <linux/random.h> > > +#include <linux/user_namespace.h> > > #include "ext2.h" > > #include "xattr.h" > > #include "acl.h" > > @@ -133,6 +134,9 @@ void ext2_free_inode (struct inode * ino > > /* Do this BEFORE marking the inode not in use or returning an error */ > > clear_inode (inode); > > > > + put_user_ns(inode->i_userns); > > + inode->i_userns = NULL; > > + > > if (ino < EXT2_FIRST_INO(sb) || > > ino > le32_to_cpu(es->s_inodes_count)) { > > ext2_error (sb, "ext2_free_inode", > > @@ -563,6 +567,7 @@ got: > > sb->s_dirt = 1; > > mark_buffer_dirty(bh2); > > inode->i_uid = current->fsuid; > > + inode->i_userns = get_task_user_ns(current); > > We have all the ext2 (and in the next patch - the ext3) inodes > attached to a particular user and prohibit access to the inodes > belonging to other tasks' namespaces, don't we? No. We provide access as though they were nobody/other. So for a large chunk of the fs that would usually be read-only acc…
creator: serue
date: 2007-06-05T12:37:36-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Serge E. Hallyn wrote: >>From nobody Mon Sep 17 00:00:00 2001 > From: Cedric Le Goater <clg@fr.ibm.com> > Date: Thu, 5 Apr 2007 12:51:51 -0400 > Subject: [PATCH 1/6] user namespace : add the framework > > Add the user namespace struct and framework > > Basically, it will allow a process to unshare its user_struct table, resetting > at the same time its own user_struct and all the associated accounting. > > A new root user (uid == 0) is added to the user namespace upon creation. Such > root users have full privileges and it seems that theses privileges should be > controlled through some means (process capabilities ?) > > The unshare is not included in this patch. > > Changes since [try #4]: > - Updated get_user_ns and put_user_ns to accept NULL, and > get_user_ns to return the namespace. > > Changes since [try #3]: > - moved struct user_namespace to files user_namespace.{c,h} > > Changes since [try #2]: > - removed 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 <clg@fr.ibm.com> > > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> > Cc: Herbert Poetzl <herbert@13thfloor.at> > Cc: Kirill Korotaev <dev@sw.ru> > Cc: "Eric W. Biederman" <ebiederm@xmission.com> > Signed-off-by: Andrew Morton <akpm@osdl.org> > > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> Acked-by: Pavel Emelianov <xemul@openvz.org> Yup. This patch is good :) > --- > > include/linux/init_task.h | 2 + > include/linux/nsproxy.h | 1 + > include/linux/sched.h | 3 +- > include/linux/user_namespace.h | 57 ++++++++++++++++++++++++++++++++++++++++ > init/Kconfig | 9 ++++++ > kernel/Makefile | 2 + > kernel/fork.c | 2 + > kernel/nsproxy.c | 10 +++++++ > kernel/sys.c | 5 ++-- > kernel/user.c | 18 ++++++------- > kernel/user_namespace.c | 43 ++++++++++++++++++++++++++++++ > 11 files changed, 138 insertions(+), 14 deletions(-) > create mode 100644…
creator: Pavel Emelianov
date: 2007-06-08T08:35:04-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > Add the user namespace struct and framework > > Basically, it will allow a process to unshare its user_struct table, resetting > at the same time its own user_struct and all the associated accounting. > > A new root user (uid == 0) is added to the user namespace upon creation. Such > root users have full privileges and it seems that theses privileges should be > controlled through some means (process capabilities ?) The whole magical-uid-0-user thing in this patch seem just wrong to me. I'll merge it anyway, mainly because I want to merge _something_ (why oh why do the git-tree guys leave everything to the last minute?) but it strikes me that there's something fundamentally wrong whenever the kernel starts "knowing" about the significance of UIDs in this fashion. It worries me. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: akpm
date: 2007-07-16T01:31:32-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Quoting Andrew Morton (akpm@linux-foundation.org): > On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > > > Add the user namespace struct and framework > > > > Basically, it will allow a process to unshare its user_struct table, resetting > > at the same time its own user_struct and all the associated accounting. > > > > A new root user (uid == 0) is added to the user namespace upon creation. Such > > root users have full privileges and it seems that theses privileges should be > > controlled through some means (process capabilities ?) > > The whole magical-uid-0-user thing in this patch seem just wrong to > me. > > I'll merge it anyway, mainly because I want to merge _something_ (why oh > why do the git-tree guys leave everything to the last minute?) but it strikes > me that there's something fundamentally wrong whenever the kernel starts > "knowing" about the significance of UIDs in this fashion. $(&(% I thought I disagreed, but now I'm pretty sure I completely agree. 'root_user' exists in the kernel right now, but the root_user checks which exist (in fork.c and sys.c) shouldn't actually be applied for root in a container, since the container may not be trusted. There is the root_user_keyring stuff - David, is that only special cased so that root's keys can be statically allocated? > It worries me. Cedric, you've probably mentioned this before, but what is wrong with the following patch? User namespaces still seem to work for me with this, but maybe I'm testing wrong. Can you give it a shot? thanks, -serge >From 743e4f5c15ff9ec4110adc9d06e39a3fb0541512 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Mon, 16 Jul 2007 10:26:25 -0400 Subject: [PATCH 1/1] userns: remove uid0 logic While 'root_user' is hard_coded in the kernel, as are uid 0 checks, removing the 'root_user' from a user namespace does not appear to break user namespaces. Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- include/linux/user_namespace…
creator: serue
date: 2007-07-16T14:34:43-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Quoting Serge E. Hallyn (serue@us.ibm.com): > Quoting Andrew Morton (akpm@linux-foundation.org): > > On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > > > > > Add the user namespace struct and framework > > > > > > Basically, it will allow a process to unshare its user_struct table, resetting > > > at the same time its own user_struct and all the associated accounting. > > > > > > A new root user (uid == 0) is added to the user namespace upon creation. Such > > > root users have full privileges and it seems that theses privileges should be > > > controlled through some means (process capabilities ?) > > > > The whole magical-uid-0-user thing in this patch seem just wrong to > > me. > > > > I'll merge it anyway, mainly because I want to merge _something_ (why oh > > why do the git-tree guys leave everything to the last minute?) but it strikes > > me that there's something fundamentally wrong whenever the kernel starts > > "knowing" about the significance of UIDs in this fashion. > > $(&(% > > I thought I disagreed, but now I'm pretty sure I completely agree. > > 'root_user' exists in the kernel right now, but the root_user checks > which exist (in fork.c and sys.c) shouldn't actually be applied for root > in a container, since the container may not be trusted. By the way, I don't think these two uses of 'user == &root_user' are legitimate. CAP_SYS_RESOURCE should probably be checked for both. Hah, it already is in fork.c, in addition to root_user check. But I guess I should take that up elsewhere. thanks, -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-07-16T14:38:48-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Serge E. Hallyn wrote: > Quoting Andrew Morton (akpm@linux-foundation.org): > >>On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: >> >> >>>Add the user namespace struct and framework >>> >>>Basically, it will allow a process to unshare its user_struct table, resetting >>>at the same time its own user_struct and all the associated accounting. >>> >>>A new root user (uid == 0) is added to the user namespace upon creation. Such >>>root users have full privileges and it seems that theses privileges should be >>>controlled through some means (process capabilities ?) >> >>The whole magical-uid-0-user thing in this patch seem just wrong to >>me. >> >>I'll merge it anyway, mainly because I want to merge _something_ (why oh >>why do the git-tree guys leave everything to the last minute?) but it strikes >>me that there's something fundamentally wrong whenever the kernel starts >>"knowing" about the significance of UIDs in this fashion. > > > $(&(% > > I thought I disagreed, but now I'm pretty sure I completely agree. > > 'root_user' exists in the kernel right now, but the root_user checks > which exist (in fork.c and sys.c) shouldn't actually be applied for root > in a container, since the container may not be trusted. This rlimit check doesn't help *untrusted* containers, so your logic is wrong here. Instead, it allows root of the container to operate in any situation. E.g. consider root user hit the limit. After that you won't be able to login/ssh to fix anything. NOTE: container root can have no CAP_SYS_RESOURCE and CAP_SYS_ADMIN as it is in OpenVZ. But in general I'm not against the patch, since in OpenVZ we can replace the check with another capability we use for VE admin - CAP_VE_SYS_ADMIN. Kirill > There is the root_user_keyring stuff - David, is that only special cased > so that root's keys can be statically allocated? > > >>It worries me. > > > Cedric, you've probably mentioned this before, but what is wrong with > the following patch? Use…
creator: dev
date: 2007-07-16T14:54:28-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Quoting Kirill Korotaev (dev@sw.ru): > Serge E. Hallyn wrote: > > Quoting Andrew Morton (akpm@linux-foundation.org): > > > >>On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > >> > >> > >>>Add the user namespace struct and framework > >>> > >>>Basically, it will allow a process to unshare its user_struct table, resetting > >>>at the same time its own user_struct and all the associated accounting. > >>> > >>>A new root user (uid == 0) is added to the user namespace upon creation. Such > >>>root users have full privileges and it seems that theses privileges should be > >>>controlled through some means (process capabilities ?) > >> > >>The whole magical-uid-0-user thing in this patch seem just wrong to > >>me. > >> > >>I'll merge it anyway, mainly because I want to merge _something_ (why oh > >>why do the git-tree guys leave everything to the last minute?) but it strikes > >>me that there's something fundamentally wrong whenever the kernel starts > >>"knowing" about the significance of UIDs in this fashion. > > > > > > $(&(% > > > > I thought I disagreed, but now I'm pretty sure I completely agree. > > > > 'root_user' exists in the kernel right now, but the root_user checks > > which exist (in fork.c and sys.c) shouldn't actually be applied for root > > in a container, since the container may not be trusted. > > This rlimit check doesn't help *untrusted* containers, so your logic is wrong here. > Instead, it allows root of the container to operate in any situation. And I'm not sure that should be the case. In my view, root of a container is equivalent to a normal user on the host system, just like root in a qemu process. > E.g. consider root user hit the limit. After that you won't be able to login/ssh to fix anything. That's fine in the container. > NOTE: container root can have no CAP_SYS_RESOURCE and CAP_SYS_ADMIN as it is in OpenVZ. And eventually we'll want that to be the default in upstream containers. But it's not the case upstream r…
creator: serue
date: 2007-07-16T15:08:00-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Quoting David Howells (dhowells@redhat.com): > Serge E. Hallyn <serue@us.ibm.com> wrote: > > > There is the root_user_keyring stuff - David, is that only special cased > > so that root's keys can be statically allocated? > > It's because the boot processes start up with UID 0, and the user_struct for > UID 0 is statically allocated (root_user). Right - thanks David. -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-07-16T15:27:49-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: On Mon, Jul 16, 2007 at 10:08:00AM -0500, Serge E. Hallyn wrote: > Quoting Kirill Korotaev (dev@sw.ru): > > Serge E. Hallyn wrote: > > > Quoting Andrew Morton (akpm@linux-foundation.org): > > > > > >>On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > > >> > > >> > > >>>Add the user namespace struct and framework > > >>> > > >>>Basically, it will allow a process to unshare its user_struct > > >>>table, resetting at the same time its own user_struct and all the > > >>>associated accounting. > > >>> > > >>>A new root user (uid == 0) is added to the user namespace upon > > >>>creation. Such root users have full privileges and it seems > > >>>that theses privileges should be controlled through some means > > >>>(process capabilities ?) > > >> > > >>The whole magical-uid-0-user thing in this patch seem just wrong > > >>to me. > > >> > > >>I'll merge it anyway, mainly because I want to merge _something_ > > >>(why oh why do the git-tree guys leave everything to the last > > >>minute?) but it strikes me that there's something fundamentally > > >>wrong whenever the kernel starts "knowing" about the significance > > >>of UIDs in this fashion. > > > > > > > > > $(&(% > > > > > > I thought I disagreed, but now I'm pretty sure I completely agree. > > > > > > 'root_user' exists in the kernel right now, but the root_user > > > checks which exist (in fork.c and sys.c) shouldn't actually be > > > applied for root in a container, since the container may not be > > > trusted. > > > > This rlimit check doesn't help *untrusted* containers, so your logic > > is wrong here. Instead, it allows root of the container to operate > > in any situation. > > And I'm not sure that should be the case. > > In my view, root of a container is equivalent to a normal user on the > host system, just like root in a qemu process. > > > E.g. consider root user hit the limit. After that you won't be able > > to login/ssh to fix anything. > > That's fine in the container. > > > NO…
creator: Herbert Poetzl
date: 2007-07-18T00:11:35-00:00

Re: [PATCH 1/6] user namespace : add the framework
type: item
description: Quoting Herbert Poetzl (herbert@13thfloor.at): > On Mon, Jul 16, 2007 at 10:08:00AM -0500, Serge E. Hallyn wrote: > > Quoting Kirill Korotaev (dev@sw.ru): > > > Serge E. Hallyn wrote: > > > > Quoting Andrew Morton (akpm@linux-foundation.org): > > > > > > > >>On Mon, 4 Jun 2007 14:40:24 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote: > > > >> > > > >> > > > >>>Add the user namespace struct and framework > > > >>> > > > >>>Basically, it will allow a process to unshare its user_struct > > > >>>table, resetting at the same time its own user_struct and all the > > > >>>associated accounting. > > > >>> > > > >>>A new root user (uid == 0) is added to the user namespace upon > > > >>>creation. Such root users have full privileges and it seems > > > >>>that theses privileges should be controlled through some means > > > >>>(process capabilities ?) > > > >> > > > >>The whole magical-uid-0-user thing in this patch seem just wrong > > > >>to me. > > > >> > > > >>I'll merge it anyway, mainly because I want to merge _something_ > > > >>(why oh why do the git-tree guys leave everything to the last > > > >>minute?) but it strikes me that there's something fundamentally > > > >>wrong whenever the kernel starts "knowing" about the significance > > > >>of UIDs in this fashion. > > > > > > > > > > > > $(&(% > > > > > > > > I thought I disagreed, but now I'm pretty sure I completely agree. > > > > > > > > 'root_user' exists in the kernel right now, but the root_user > > > > checks which exist (in fork.c and sys.c) shouldn't actually be > > > > applied for root in a container, since the container may not be > > > > trusted. > > > > > > This rlimit check doesn't help *untrusted* containers, so your logic > > > is wrong here. Instead, it allows root of the container to operate > > > in any situation. > > > > And I'm not sure that should be the case. > > > > In my view, root of a container is equivalent to a normal user on the > > host system, just like root in a qemu process. > > > > > E…
creator: serue
date: 2007-07-18T14:21:51-00:00