execns syscall and user namespace

The 32bits syscall is not implemented.

This patch adds the execns() syscall to the s390 architecture.

Quoted 1 line · Cedric Le Goater

This patch adds the execns() syscall to the s390 architecture.

Fixed whitespace and added glue code for compat_do_execns.

Thanks !

Both patches are in my patchset now which compiles and boots fine on s390x. I'll build 32 bits binaries to try them.

Why did you protect sys32_execns, sys_execns and compat_do_execns () with #ifdef CONFIG_UTS_NS ? Did you need to ?

Quoted 7 lines · Cedric Le Goater

Thanks !

Both patches are in my patchset now which compiles and boots fine on s390x. I'll build 32 bits binaries to try them.

Why did you protect sys32_execns, sys_execns and compat_do_execns () with #ifdef CONFIG_UTS_NS ? Did you need to ?

Yes, without the #ifdefs I get compile time warnings.

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

Signed-off-by Cedric Le Goater <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Kirill Korotaev <[email protected]>

Cc Andrey Savochkin <[email protected]>

Cc Eric W. Biederman <[email protected]>

Cc Herbert Poetzl <[email protected]>

Cc Sam Vilain <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Dave Hansen <[email protected]>

---
 fs/ioprio.c               |    5 +
 include/linux/init_task.h |    2 
 include/linux/nsproxy.h   |    2 
 include/linux/sched.h     |    6 +-
 include/linux/user.h      |   45 +++++++++++++++
 init/Kconfig              |    8 ++
 kernel/nsproxy.c          |   15 ++++-
 kernel/sys.c              |    8 +-
 kernel/user.c             |  135 ++++++++++++++++++++++++++++++++++++++++++----
 9 files changed, 208 insertions(+), 18 deletions(-)

Index: 2.6.18-rc1-mm1/kernel/user.c
===================================================================

kernel/user.c +125 -10

@@ -14,20 +14,28 @@
 #include <linux/bitops.h>
 #include <linux/key.h>
 #include <linux/interrupt.h>
+#include <linux/user.h>
+#include <linux/module.h>
+#include <linux/nsproxy.h>
 
 /*
  * UID task count cache, to get fast user lookup in "alloc_uid"
  * when changing user ID's (ie setuid() and friends).
  */
 
-#define UIDHASH_BITS (CONFIG_BASE_SMALL ? 3 : 8)
-#define UIDHASH_SZ		(1 << UIDHASH_BITS)
 #define UIDHASH_MASK		(UIDHASH_SZ - 1)
 #define __uidhashfn(uid)	(((uid >> UIDHASH_BITS) + uid) & UIDHASH_MASK)
-#define uidhashentry(uid)	(uidhash_table + __uidhashfn((uid)))
+#define uidhashentry(ns, uid)	((ns)->uidhash_table + __uidhashfn((uid)))
 
 static kmem_cache_t *uid_cachep;
-static struct list_head uidhash_table[UIDHASH_SZ];
+
+struct user_namespace init_user_ns = {
+	.kref = {
+		.refcount	= ATOMIC_INIT(2),
+	},
+};
+
+EXPORT_SYMBOL_GPL(init_user_ns);
 
 /*
  * The uidhash_lock is mostly taken from process context, but it is

@@ -84,19 +92,126 @@ static inline struct user_struct *uid_ha
 	return NULL;
 }
 
+
+#ifdef CONFIG_USER_NS
+
+/*
+ * Clone a new ns copying an original user ns, setting refcount to 1
+ * @old_ns: namespace to clone
+ * Return NULL on error (failure to kmalloc), new ns otherwise
+ */
+static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
+{
+	struct user_namespace *ns;
+
+	ns = kmalloc(sizeof(struct user_namespace), GFP_KERNEL);
+	if (ns) {
+		int n;
+		struct user_struct *new_user;
+
+		kref_init(&ns->kref);
+
+		for(n = 0; n < UIDHASH_SZ; ++n)
+			INIT_LIST_HEAD(ns->uidhash_table + n);
+
+		/* Insert default root user. An alternate solution
+		 * would be to let the system allocate a new user 0
+		 * for this namespace and work on capabilities to give
+		 * the process some privileges.
+		 */
+		spin_lock_irq(&uidhash_lock);
+		uid_hash_insert(&root_user, uidhashentry(ns, 0));
+		spin_unlock_irq(&uidhash_lock);
+
+		/* Reset current->user with a new one */
+		new_user = alloc_uid(ns, current->uid);
+		if (!new_user) {
+			kfree(ns);
+			return NULL;
+		}
+
+		switch_uid(new_user);
+	}
+	return ns;
+}
+
+/*
+ * unshare the current process' user namespace.
+ */
+int unshare_user_ns(unsigned long unshare_flags,
+		    struct user_namespace **new_user)
+{
+	if (unshare_flags & CLONE_NEWUSER) {
+		if (!capable(CAP_SYS_ADMIN))
+			return -EPERM;
+
+		*new_user = clone_user_ns(current->nsproxy->user_ns);
+		if (!*new_user)
+			return -ENOMEM;
+	}
+
+	return 0;
+}
+
+/*
+ * Copy task tsk's user namespace, or clone it if flags specifies
+ * CLONE_NEWUSER. In latter case, changes to the user namespace of
+ * this process won't be seen by parent, and vice versa.
+ */
+int copy_user_ns(int flags, struct task_struct *tsk)
+{
+	struct user_namespace *old_ns = tsk->nsproxy->user_ns;
+	struct user_namespace *new_ns;
+	int err = 0;
+
+	if (!old_ns)
+		return 0;
+
+	get_user_ns(old_ns);
+
+	if (!(flags & CLONE_NEWUSER))
+		return 0;
+
+	if (!capable(CAP_SYS_ADMIN)) {
+		err = -EPERM;
+		goto out;
+	}
+
+	new_ns = clone_user_ns(old_ns);
+	if (!new_ns) {
+		err = -ENOMEM;
+		goto out;
+	}
+	tsk->nsproxy->user_ns = new_ns;
+
+out:
+	put_user_ns(old_ns);
+	return err;
+}
+
+void free_user_ns(struct kref *kref)
+{
+	struct user_namespace *ns;
+
+	ns = container_of(kref, struct user_namespace, kref);
+	kfree(ns);
+}
+
+#endif /* CONFIG_USER_NS */
+
 /*
  * Locate the user_struct for the passed UID.  If found, take a ref on it.  The
  * caller must undo that ref with free_uid().
  *
  * If the user_struct could not be found, return NULL.
  */
-struct user_struct *find_user(uid_t uid)
+struct user_struct *find_user(struct user_namespace *ns, uid_t uid)
 {
 	struct user_struct *ret;
 	unsigned long flags;
 
 	spin_lock_irqsave(&uidhash_lock, flags);
-	ret = uid_hash_find(uid, uidhashentry(uid));
+	ret = uid_hash_find(uid, uidhashentry(ns, uid));
 	spin_unlock_irqrestore(&uidhash_lock, flags);
 	return ret;
 }

@@ -120,9 +235,9 @@ void free_uid(struct user_struct *up)
 	}
 }
 
-struct user_struct * alloc_uid(uid_t uid)
+struct user_struct * alloc_uid(struct user_namespace *ns, uid_t uid)
 {
-	struct list_head *hashent = uidhashentry(uid);
+	struct list_head *hashent = uidhashentry(ns, uid);
 	struct user_struct *up;
 
 	spin_lock_irq(&uidhash_lock);

@@ -200,11 +315,11 @@ static int __init uid_cache_init(void)
 			0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
 
 	for(n = 0; n < UIDHASH_SZ; ++n)
-		INIT_LIST_HEAD(uidhash_table + n);
+		INIT_LIST_HEAD(init_user_ns.uidhash_table + n);
 
 	/* Insert the root user immediately (init already runs as root) */
 	spin_lock_irq(&uidhash_lock);
-	uid_hash_insert(&root_user, uidhashentry(0));
+	uid_hash_insert(&root_user, uidhashentry(&init_user_ns, 0));
 	spin_unlock_irq(&uidhash_lock);
 
 	return 0;

Index: 2.6.18-rc1-mm1/include/linux/nsproxy.h
===================================================================

include/linux/nsproxy.h +2 -0

@@ -7,6 +7,7 @@
 struct namespace;
 struct uts_namespace;
 struct ipc_namespace;
+struct user_namespace;
 
 /*
  * A structure to contain pointers to all per-process

@@ -25,6 +26,7 @@ struct nsproxy {
 	spinlock_t nslock;
 	struct uts_namespace *uts_ns;
 	struct ipc_namespace *ipc_ns;
+	struct user_namespace *user_ns;
 	struct namespace *namespace;
 };
 extern struct nsproxy init_nsproxy;

Index: 2.6.18-rc1-mm1/include/linux/user.h
===================================================================

include/linux/user.h +45 -0

@@ -1 +1,46 @@
+#ifndef _LINUX_USER_H
+#define _LINUX_USER_H
+
 #include <asm/user.h>
+
+#define UIDHASH_BITS (CONFIG_BASE_SMALL ? 3 : 8)
+#define UIDHASH_SZ		(1 << UIDHASH_BITS)
+
+struct user_namespace {
+	struct kref		kref;
+	struct list_head	uidhash_table[UIDHASH_SZ];
+};
+
+extern struct user_namespace init_user_ns;
+
+static inline void get_user_ns(struct user_namespace *ns)
+{
+	kref_get(&ns->kref);
+}
+
+#ifdef CONFIG_USER_NS
+extern int unshare_user_ns(unsigned long unshare_flags,
+			   struct user_namespace **new_user);
+extern int copy_user_ns(int flags, struct task_struct *tsk);
+extern void free_user_ns(struct kref *kref);
+
+static inline void put_user_ns(struct user_namespace *ns)
+{
+	kref_put(&ns->kref, free_user_ns);
+}
+#else
+static inline int unshare_user_ns(unsigned long unshare_flags,
+			struct user_namespace **new_user)
+{
+	return -EINVAL;
+}
+static inline int copy_user_ns(int flags, struct task_struct *tsk)
+{
+	return 0;
+}
+static inline void put_user_ns(struct user_namespace *ns)
+{
+}
+#endif /* CONFIG_USER_NS */
+
+#endif /* _LINUX_USER_H */

Index: 2.6.18-rc1-mm1/kernel/nsproxy.c
===================================================================

kernel/nsproxy.c +14 -1

@@ -18,6 +18,7 @@
 #include <linux/nsproxy.h>
 #include <linux/namespace.h>
 #include <linux/utsname.h>
+#include <linux/user.h>
 
 static inline void get_nsproxy(struct nsproxy *ns)
 {

@@ -65,6 +66,8 @@ struct nsproxy *dup_namespaces(struct ns
 			get_uts_ns(ns->uts_ns);
 		if (ns->ipc_ns)
 			get_ipc_ns(ns->ipc_ns);
+		if (ns->user_ns)
+			get_user_ns(ns->user_ns);
 	}
 
 	return ns;

@@ -85,7 +88,8 @@ int copy_namespaces(int flags, struct ta
 
 	get_nsproxy(old_ns);
 
-	if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC)))
+	if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC |
+			CLONE_NEWUSER)))
 		return 0;
 
 	new_ns = clone_namespaces(old_ns);

@@ -108,10 +112,17 @@ int copy_namespaces(int flags, struct ta
 	if (err)
 		goto out_ipc;
 
+	err = copy_user_ns(flags, tsk);
+	if (err)
+		goto out_user;
+
 out:
 	put_nsproxy(old_ns);
 	return err;
 
+out_user:
+	if (new_ns->ipc_ns)
+		put_ipc_ns(new_ns->ipc_ns);
 out_ipc:
 	if (new_ns->uts_ns)
 		put_uts_ns(new_ns->uts_ns);

@@ -132,5 +143,7 @@ void free_nsproxy(struct nsproxy *ns)
 			put_uts_ns(ns->uts_ns);
 		if (ns->ipc_ns)
 			put_ipc_ns(ns->ipc_ns);
+		if (ns->user_ns)
+			put_user_ns(ns->user_ns);
 		kfree(ns);
 }

Index: 2.6.18-rc1-mm1/include/linux/sched.h
===================================================================

include/linux/sched.h +4 -2

@@ -26,6 +26,7 @@
 #define CLONE_STOPPED		0x02000000	/* Start in stopped state */
 #define CLONE_NEWUTS		0x04000000	/* New utsname group? */
 #define CLONE_NEWIPC		0x08000000	/* New ipcs */
+#define CLONE_NEWUSER		0x10000000	/* New user */
 
 /*
  * Scheduling policies

@@ -243,6 +244,7 @@ extern signed long schedule_timeout_unin
 asmlinkage void schedule(void);
 
 struct nsproxy;
+struct user_namespace;
 
 /* Maximum number of active map areas.. This is a random (large) number */
 #define DEFAULT_MAX_MAP_COUNT	65536

@@ -537,7 +539,7 @@ struct user_struct {
 	uid_t uid;
 };
 
-extern struct user_struct *find_user(uid_t);
+extern struct user_struct *find_user(struct user_namespace *, uid_t);
 
 extern struct user_struct root_user;
 #define INIT_USER (&root_user)

@@ -1204,7 +1206,7 @@ extern void set_special_pids(pid_t sessi
 extern void __set_special_pids(pid_t session, pid_t pgrp);
 
 /* per-UID process charging. */
-extern struct user_struct * alloc_uid(uid_t);
+extern struct user_struct * alloc_uid(struct user_namespace *, uid_t);
 static inline struct user_struct *get_uid(struct user_struct *u)
 {
 	atomic_inc(&u->__count);

Index: 2.6.18-rc1-mm1/init/Kconfig
===================================================================

init/Kconfig +8 -0

@@ -237,6 +237,14 @@ config UTS_NS
 	  vservers, to use uts namespaces to provide different
 	  uts info for different servers.  If unsure, say N.
 
+config USER_NS
+	bool "User Namespaces"
+	default n
+	help
+	  Support user namespaces.  This allows containers, i.e.
+	  vservers, to use user namespaces to provide different
+	  user info for different servers.  If unsure, say N.
+
 config AUDIT
 	bool "Auditing support"
 	depends on NET

Index: 2.6.18-rc1-mm1/include/linux/init_task.h
===================================================================

include/linux/init_task.h +2 -0

@@ -8,6 +8,7 @@
 #include <linux/lockdep.h>
 #include <linux/notifier.h>
 #include <linux/ipc.h>
+#include <linux/user.h>
 
 #define INIT_FDTABLE \
 {							\

@@ -78,6 +79,7 @@ extern struct nsproxy init_nsproxy;
 	.uts_ns		= &init_uts_ns,					\
 	.namespace	= NULL,						\
 	INIT_IPC_NS(ipc_ns)						\
+	.user_ns	= &init_user_ns,				\
 }
 
 #define INIT_SIGHAND(sighand) {						\

Index: 2.6.18-rc1-mm1/fs/ioprio.c
===================================================================

fs/ioprio.c +3 -2

@@ -25,6 +25,7 @@
 #include <linux/capability.h>
 #include <linux/syscalls.h>
 #include <linux/security.h>
+#include <linux/nsproxy.h>
 
 static int set_task_ioprio(struct task_struct *task, int ioprio)
 {

@@ -101,7 +102,7 @@ asmlinkage long sys_ioprio_set(int which
 			if (!who)
 				user = current->user;
 			else
-				user = find_user(who);
+				user = find_user(current->nsproxy->user_ns, who);
 
 			if (!user)
 				break;

@@ -171,7 +172,7 @@ asmlinkage long sys_ioprio_get(int which
 			if (!who)
 				user = current->user;
 			else
-				user = find_user(who);
+				user = find_user(current->nsproxy->user_ns, who);
 
 			if (!user)
 				break;

Index: 2.6.18-rc1-mm1/kernel/sys.c
===================================================================

kernel/sys.c +5 -4

@@ -544,7 +544,8 @@ asmlinkage long sys_setpriority(int whic
 			if (!who)
 				who = current->uid;
 			else
-				if ((who != current->uid) && !(user = find_user(who)))
+				if ((who != current->uid) &&
+					!(user = find_user(current->nsproxy->user_ns, who)))
 					goto out_unlock;	/* No processes for this user */
 
 			do_each_thread(g, p)

@@ -602,7 +603,8 @@ asmlinkage long sys_getpriority(int whic
 			if (!who)
 				who = current->uid;
 			else
-				if ((who != current->uid) && !(user = find_user(who)))
+				if ((who != current->uid) &&
+					!(user = find_user(current->nsproxy->user_ns, who)))
 					goto out_unlock;	/* No processes for this user */
 
 			do_each_thread(g, p)

@@ -935,7 +937,7 @@ static int set_user(uid_t new_ruid, int 
 {
 	struct user_struct *new_user;
 
-	new_user = alloc_uid(new_ruid);
+	new_user = alloc_uid(current->nsproxy->user_ns, new_ruid);
 	if (!new_user)
 		return -EAGAIN;
 
 
--

I wonder about another namespace coupling I found thinking about your patches.

Lets take a look at sys_setpriority() or any other function calling find_user():
it can change the priority for all user or group processes like:

do_each_thread_ve(g, p) {
   if (p->uid == who)
       error = set_one_prio(p, niceval, error);
} while_each_thread_ve(g, p);

which essentially means that user-namespace becomes coupled with process-namespace. Sure, we can check in every such place for
p->nsproxy->user_ns == current->nsproxy->user_ns
condition. But this a way IMHO leading to kernel full of security crap which is hardly maintainable.

Another example of not so evident coupling here:
user structure maintains number of processes/opened files/sigpending/locked_shm etc.
if a single user can belong to different proccess/ipc/... namespaces all these becomes unusable.

Small patch comment:
- what is the reason in adding 2nd arg to find_user()?

Quoted 8 lines

Lets take a look at sys_setpriority() or any other function calling find_user():
it can change the priority for all user or group processes like:

do_each_thread_ve(g, p) {
if (p->uid == who)

      error = set_one_prio(p, niceval, error);
} while_each_thread_ve(g, p);

eh. this is openvz code ! thanks :)

Quoted 5 lines

which essentially means that user-namespace becomes coupled with process-namespace. Sure, we can check in every such place for p->nsproxy->user_ns == current->nsproxy->user_ns condition. But this a way IMHO leading to kernel full of security crap which is hardly maintainable.

only 4 syscalls use find_user() : sys_setpriority, sys_getpriority, sys_ioprio_set, sys_ioprio_get and they use it very simply to check if a user_struct exists for a given uid. So, it should be OK. But please see the attached patch.

Quoted 5 lines

Another example of not so evident coupling here:
user structure maintains number of processes/opened files/sigpending/locked_shm etc.
if a single user can belong to different proccess/ipc/... namespaces all these becomes unusable.

this is the purpose of execns.

user namespace can't be unshared through the unshare syscall().

they can
only be unshared through execns() which flushes the previous image of the process. However, the execns patch still needs to close files without the close-on-exec flag. I didn't do it yet. lazy me :)

Quoted 4 lines

Quoted 4 lines

Lets take a look at sys_setpriority() or any other function calling find_user():
it can change the priority for all user or group processes like:

Quoted 7 lines

Quoted 4 lines

do_each_thread_ve(g, p) {
if (p->uid == who)

      error = set_one_prio(p, niceval, error);
} while_each_thread_ve(g, p);

eh. this is openvz code ! thanks :)

it doesn't matter :)

2.6.17 code is:
do_each_thread(g, p)
if (p->uid == who)
error = set_one_prio(p, niceval,

error);
                       while_each_thread(g, p);

when introducing process namespaces we will have to isolate processes somehow and this loop, agree?

in this case 1 user-namespace can belong to 2 process-namespaces, agree? how do you see this loop in the future making sure that above situation is handled correctly?

how many other such places do we have?

Quoted 10 lines

Quoted 5 lines

which essentially means that user-namespace becomes coupled with process-namespace. Sure, we can check in every such place for p->nsproxy->user_ns == current->nsproxy->user_ns condition. But this a way IMHO leading to kernel full of security crap which is hardly maintainable.

only 4 syscalls use find_user() : sys_setpriority, sys_getpriority, sys_ioprio_set, sys_ioprio_get and they use it very simply to check if a user_struct exists for a given uid. So, it should be OK. But please see the attached patch.

the problem is not in find_user() actually. but in uid comparison inside some kind of process iteration loop. In this case you select processes p which belong to both namespaces simultenously: i.e. processes p which belong both to user-namespace U and process-namespace P.

I hope I was more clear this time :)

Quoted 7 lines

Quoted 5 lines

Another example of not so evident coupling here:
user structure maintains number of processes/opened files/sigpending/locked_shm etc.
if a single user can belong to different proccess/ipc/... namespaces all these becomes unusable.

Quoted 3 lines

this is the purpose of execns.

user namespace can't be unshared through the unshare syscall().

why? we do it fine in OpenVZ.

Another example of not so evident coupling here:
user structure maintains number of processes/opened files/sigpending/locked_shm etc.
if a single user can belong to different proccess/ipc/... namespaces all these becomes unusable.

Quoted 5 lines

Another example of not so evident coupling here:
user structure maintains number of processes/opened files/sigpending/locked_shm etc.
if a single user can belong to different proccess/ipc/... namespaces all these becomes unusable.

Why do the count of the number of objects a user has become unusable if they can count objects in multiple namespaces?

Namespaces are about how names are looked up and how names are created. Namespaces are not about the objects those names refer to.

Quoted 2 lines

Quoted 2 lines

Another example of not so evident coupling here:
user structure maintains number of processes/opened

files/sigpending/locked_shm

Quoted 7 lines

Quoted 3 lines

etc.
if a single user can belong to different proccess/ipc/... namespaces all these becomes unusable.

Why do the count of the number of objects a user has become unusable if they can count objects in multiple namespaces? Namespaces are about how names are looked up and how names are created. Namespaces are not about the objects those names refer to.

One example below, which I believe is a bug due to coupling. Will be glad to hear your opinion on this.

Let user u to unshare its process namespace and run e.g. httpd inside newly created 2nd process namespace.
Now imagine that user u hits his process rlimit.
He can't kill his httpd's because they are in another process namespace. He can kill visible to his bash processes from
1st process namespace, but httpd can spawn childs more after that. So we end up with the situation
when user u can't control his processes, nor run any other processes in his bash.

I'm fine with such situations, since we need containers mostly, but what makes me
really afraid is that it introduces hard to find/fix/maintain issues. I have no any other concerns.

Quoted 3 lines

I'm fine with such situations, since we need containers mostly, but what makes me really afraid is that it introduces hard to find/fix/maintain issues. I have no any other concerns.

Hard to find and maintain problems I agree should be avoided. There are only two ways I can see coping with the weird interactions that might occur.

1) Assert weird interactions will never happen, don't worry about it,
and stomp on any place where they can occur. (A fully isolated container approach).

2) Assume weird interactions happen and write the code so that it simply works if those interactions happen, because for each namespace you have made certain the code works regardless of which namespace the objects are in.

The second case is slightly harder. But as far as I can tell it is more robust and allows for much better incremental development.

hmm, slightly, I would say much harder and these weird interactions are very hard to anticipate without some experience in the field. We could continue on arguing for ages without making any progress.

let's apply that incremental development approach now. Let's work on simple namespaces which would make _some_ container scenarios possible and not all. IMHO, that would mean tying some namespaces together and find a way to unshare them safely as a whole. Get some experience on it and then work on unsharing some more independently for the benefit of more use case scenarios. I like the concept and I think it will be useful.

just being pragmatic, i like things to start working in simple cases before over optimizing them.

We need a formula for doing incremental development that will allow us to make headway while not seeing the entire picture all at once. The scope is just too large.

Quoted 3 lines · Eric W. Biederman

We need a formula for doing incremental development that will allow us to make headway while not seeing the entire picture all at once. The scope is just too large.

Definitely. We need a low-risk development environment where we can put test-fit pieces together, but also not worry too much of we have to rip pieces out, or completely change them.

I'm not sure we *need* to rewrite things for review-ability later. I think some of us have gotten pretty good at keeping our development in reviewable bits as we go along.

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

Signed-off-by Cedric Le Goater <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Kirill Korotaev <[email protected]>

Cc Andrey Savochkin <[email protected]>

Cc Eric W. Biederman <[email protected]>

Cc Herbert Poetzl <[email protected]>

Cc Sam Vilain <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Dave Hansen <[email protected]>

---
 fs/ioprio.c               |    5 +
 include/linux/init_task.h |    2 
 include/linux/nsproxy.h   |    2 
 include/linux/sched.h     |    6 +-
 include/linux/user.h      |   45 +++++++++++++++
 init/Kconfig              |    8 ++
 kernel/nsproxy.c          |   15 ++++-
 kernel/sys.c              |    8 +-
 kernel/user.c | 135 ++++++++++++++++++++++++++++++++++++++++++----

Quoted 6 lines · Cedric Le Goater

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

Quoted 6 lines

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

It is completely the wrong thing for a the root_user to span multiple namespaces as you describe. It is important for uid 0 in other namespaces to not have the privileges of the root_user. That is half the point.

Too many files in sysfs and proc don't require caps but instead simply limit things to uid 0. Having a separate uid 0 in the different namespaces instantly makes all of these files inaccessible, and keeps processes from doing something bad.

To a filesystem a uid does not share a uid namespace with the only things that should be accessible are those things that are readable/writeable by everyone. Unless the filesystem has provisions for storing multiple uid namespaces not files should be able to be created. Think NFS root squash.

Quoted 10 lines

Signed-off-by Cedric Le Goater <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Kirill Korotaev <[email protected]>

Cc Andrey Savochkin <[email protected]>

Cc Eric W. Biederman <[email protected]>

Cc Herbert Poetzl <[email protected]>

Cc Sam Vilain <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Dave Hansen <[email protected]>

Quoted 10 lines

---
 fs/ioprio.c               |    5 +
 include/linux/init_task.h |    2 
 include/linux/nsproxy.h   |    2 
 include/linux/sched.h     |    6 +-
 include/linux/user.h      |   45 +++++++++++++++
 init/Kconfig              |    8 ++
 kernel/nsproxy.c          |   15 ++++-
 kernel/sys.c              |    8 +-
 kernel/user.c | 135 ++++++++++++++++++++++++++++++++++++++++++----

This patch looks extremly incomplete.

Every comparison of a user id needs to compare the tuple (user namespace, user id) or it needs to compare struct users.

Ever comparison of a group id needs to compare the tuple (user namespace, group id) or it needs to compare struct users.

I think the key infrastructure needs to be looked at here as well.

There needs to be a user namespace association for mounted filesystems.

We need a discussion about how we handle map users from one user namespace to another, because without some form of mapping so many things become inaccessible that the system is almost useless.

I believe some of the key infrastructure which is roughly kerberos authentication tokens could be used for this purpose.

A user namespace is a big thing. What I see here doesn't even seem to scratch the surface.

Eric

Quoted 20 lines · Eric W. Biederman

Quoted 6 lines · Cedric Le Goater

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

Quoted 6 lines

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

It is completely the wrong thing for a the root_user to span multiple namespaces as you describe. It is important for uid 0 in other namespaces to not have the privileges of the root_user. That is half the point.

Quoted 4 lines

Too many files in sysfs and proc don't require caps but instead simply limit things to uid 0. Having a separate uid 0 in the different namespaces instantly makes all of these files inaccessible, and keeps processes from doing something bad.

well, here I'd definitely prefer to fix up that 'broken' entries by adding proper capability checks, and maybe even a bunch of new capabilities (i.e. 64bit caps and such) first, because IMHO the capability system is the 'proper' method to protect them in the first place

Quoted 5 lines

To a filesystem a uid does not share a uid namespace with the only things that should be accessible are those things that are readable/writeable by everyone. Unless the filesystem has provisions for storing multiple uid namespaces not files should be able to be created. Think NFS root squash.

that's where file tagging as Linux-VServer does it can be used to 'share' a partition between different guests (and have separate disk limits and quotas)

Quoted 6 lines · Cedric Le Goater

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

Quoted 6 lines

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

It is completely the wrong thing for a the root_user to span multiple namespaces as you describe. It is important for uid 0 in other namespaces to not have the privileges of the root_user. That is half the point.

Too many files in sysfs and proc don't require caps but instead simply limit things to uid 0. Having a separate uid 0 in the different namespaces instantly makes all of these files inaccessible, and keeps processes from doing something bad.

To a filesystem a uid does not share a uid namespace with the only things that should be accessible are those things that are readable/writeable
by everyone. Unless the filesystem has provisions for storing multiple
uid namespaces not files should be able to be created. Think NFS root squash.

Every comparison of a user id needs to compare the tuple (user namespace, user id) or it needs to compare struct users.

Ever comparison of a group id needs to compare the tuple (user namespace, group id) or it needs to compare struct users.

I think the key infrastructure needs to be looked at here as well.

There needs to be a user namespace association for mounted filesystems.

We need a discussion about how we handle map users from one user namespace to another, because without some form of mapping so many things become inaccessible that the system is almost useless.

I believe some of the key infrastructure which is roughly kerberos authentication tokens could be used for this purpose.

A user namespace is a big thing. What I see here doesn't even seem to scratch the surface.

Quoted 15 lines · Eric W. Biederman

Quoted 6 lines · Cedric Le Goater

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

Quoted 6 lines

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

Quoted 3 lines

It is completely the wrong thing for a the root_user to span multiple namespaces as you describe. It is important for uid 0 in other namespaces to not have the privileges of the root_user. That is half the point.

ok good. that's what i thought also.

Quoted 4 lines

Too many files in sysfs and proc don't require caps but instead simply limit things to uid 0. Having a separate uid 0 in the different namespaces instantly makes all of these files inaccessible, and keeps processes from doing something bad.

but in order to be useful, the uid 0 in other namespaces will need to have some capabilities.

Quoted 5 lines

To a filesystem a uid does not share a uid namespace with the only things that should be accessible are those things that are readable/writeable
by everyone. Unless the filesystem has provisions for storing multiple
uid namespaces not files should be able to be created. Think NFS root squash.

I think user namespace should be unshared with filesystem. if not, the user/admin should know what is doing.

Quoted 5 lines

Every comparison of a user id needs to compare the tuple (user namespace, user id) or it needs to compare struct users.

Ever comparison of a group id needs to compare the tuple (user namespace, group id) or it needs to compare struct users.

yes, that would be the ultimate user namespace.

I think that this first patchset lays some infrastructure that is already quite usable in a container which already isolates file, pids, etc and not only users.

now, we could work on extending it to support fine grain user namespace which i think can done on top of this first patch.

Quoted 3 lines

I think the key infrastructure needs to be looked at here as well.

There needs to be a user namespace association for mounted filesystems.

yes you could expect that to check the i_uid against fsuid but should we enforce it completely ?

we already have an issue today with a simple NFS mount on 2 hosts with different user mapping. namespace can't fix all issues.

Quoted 6 lines

We need a discussion about how we handle map users from one user namespace to another, because without some form of mapping so many things become inaccessible that the system is almost useless.

I believe some of the key infrastructure which is roughly kerberos authentication tokens could be used for this purpose.

please elaborate ? i'm not sure to understand why you want to use the keys to map users.

Quoted 2 lines

A user namespace is a big thing. What I see here doesn't even seem to scratch the surface.

good let's start digging !

Quoted 2 lines

I think user namespace should be unshared with filesystem. if not, the user/admin should know what is doing.

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem.

Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

Quoted 4 lines

Quoted 2 lines

I believe some of the key infrastructure which is roughly kerberos authentication tokens could be used for this purpose.

please elaborate ? i'm not sure to understand why you want to use the keys to map users.

keys are essentially security credentials for something besides the local kernel. Think kerberos tickets. That makes the keys the obvious place to say what uid you are in a different user namespace and similar things.

Quoted 6 lines · Eric W. Biederman

Quoted 2 lines

I think user namespace should be unshared with filesystem. if not, the user/admin should know what is doing.

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem.

ok. so once you're in such a user namespace, you can't unshare from it without loosing access to all your files ?

Quoted 2 lines

Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

well, this is what is currently done without user namespaces.

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

I believe some of the key infrastructure which is roughly kerberos authentication tokens could be used for this purpose.

please elaborate ? i'm not sure to understand why you want to use the keys to map users.

Quoted 4 lines

keys are essentially security credentials for something besides the local kernel. Think kerberos tickets. That makes the keys the obvious place to say what uid you are in a different user namespace and similar things.

what about performance ? wouldn't that slow the checking ?

Rather than try to store (uid, namespace) on the filesystem, I like the idea of doing something like

	mount --bind -o ro --uidswap 500,1001 --uidswap 501,0 /home /home

In other words, when you unshare the user namespace, nothing filesystem-related changes unless you also unshare the fs-namespace and set uid info on the vfsmount. This is fully backward-compatible and should have no overhead if you don't need the feature.

Maybe. I really think the sane semantics are in a different uid namespace. So you can't assumes uids are the same. Otherwise you can't handle open file descriptors or files passed through unix domain sockets.

Quoted 3 lines · Eric W. Biederman

Maybe. I really think the sane semantics are in a different uid namespace. So you can't assumes uids are the same. Otherwise you can't handle open file descriptors or files passed through unix domain sockets.

Eric, could you explain this a little bit more? I'm not sure I understand the details of why this is a problem?

All comparisons of a user equality need to be of the tuple (user namespace, user id). Any comparison that does not do that is an optimization.

So my impression was that Cedric's patchset was overoptimized because it did not change most of the uid comparisons, to (user namespace, user id).

Because you can have access to files created in another user namespace it is very unlikely that optimization will apply very frequently. The easy scenario to get access to a file descriptor from another context is to consider unix domain sockets.

Quoted 1 line · Eric W. Biederman

All comparisons of a user equality need to be of the tuple (user namespace,

user id).

Quoted 1 line

Any comparison that does not do that is an optimization.

...

Quoted 2 lines

So my impression was that Cedric's patchset was overoptimized because it did not change most of the uid comparisons, to (user namespace, user id).

I might just be tempted to call them bugs so people understand what I'm talking about ;)

Quoted 2 lines

Because you can have access to files created in another user namespace it is very unlikely that optimization will apply very frequently. The easy

scenario

Quoted 2 lines

to get access to a file descriptor from another context is to consider unix domain sockets.

OK, so you're saying that the lack of checks will cause problems rarely, and that passing a fd across a unix domain sockets is one of the times when you _could_ encounter this problem?

I think for filesystems like /proc and /sys that there will normally be problems. However many of those problems can be rationalized away as a reasonable optimization, or are not immediately apparent.

Passing a file descriptor between process in a unix domain socket is a case where I can easily construct scenarios where there are indisputable problems. It is one of my standard thought experiments to see if a namespace is sound.

Quoted 3 lines · Eric W. Biederman

I think for filesystems like /proc and /sys that there will normally be problems. However many of those problems can be rationalized away as a reasonable optimization, or are not immediately apparent.

Could you talk about some of these problems?

Quoted 4 lines

Passing a file descriptor between process in a unix domain socket is a case where I can easily construct scenarios where there are indisputable problems. It is one of my standard thought experiments to see if a namespace is sound.

Care to share some of those indisputable problems?

Quoted 6 lines · Dave Hansen

Quoted 3 lines · Eric W. Biederman

I think for filesystems like /proc and /sys that there will normally be problems. However many of those problems can be rationalized away as a reasonable optimization, or are not immediately apparent.

Could you talk about some of these problems?

Already mentioned but. rw permissions on sensitive files are for uid == 0. No capability checks are performed.

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Dave Hansen

Quoted 3 lines · Eric W. Biederman

I think for filesystems like /proc and /sys that there will normally be problems. However many of those problems can be rationalized away as a reasonable optimization, or are not immediately apparent.

Quoted 4 lines

Quoted 1 line

Could you talk about some of these problems?

Already mentioned but. rw permissions on sensitive files are for uid == 0. No capability checks are performed.

As Herbert (IIRC) pointed out that could/should be fixed.

Review

Quoted 4 lines · Eric W. Biederman

(quoted diff) +2 -1

-       if (current->fsuid == inode->i_uid)
+       if ((current->fsuid == inode->i_uid) &&
+               (current->nsproxy->user_ns == inode->i_sb->user_ns))
                mode >>= 6; 

I really don't think assigning a user namespace to a superblock is the right way to go. Seems to me like the _view_ into the filesystem is what you want to modify. That would seem to me to mean that each 'struct namespace' (filesystem namespace) or vfsmount would be assigned a corresponding user namespace, *not* the superblock.

yes, of course, vfsmount, which I assume is what Eric meant?

Which means we'd have to do this at permission() using the nameidata, or pass nd to generic_permission.

Quoted 4 lines · Serge E. Hallyn

yes, of course, vfsmount, which I assume is what Eric meant?

Which means we'd have to do this at permission() using the nameidata, or pass nd to generic_permission.

Yeah, I think so. But, this is well into Al territory, and there might be a better way.

Quoted 3 lines · Dave Hansen

Quoted 2 lines · Serge E. Hallyn

yes, of course, vfsmount, which I assume is what Eric meant?

Quoted 5 lines

Quoted 2 lines

Which means we'd have to do this at permission() using the nameidata, or pass nd to generic_permission.

Yeah, I think so. But, this is well into Al territory, and there might be a better way.

Well until we get that sorted out I will keep picking on i_sb.

Quoted 8 lines · Eric W. Biederman

Quoted 6 lines · Dave Hansen

Quoted 4 lines · Serge E. Hallyn

yes, of course, vfsmount, which I assume is what Eric meant?

Which means we'd have to do this at permission() using the nameidata, or pass nd to generic_permission.

Quoted 4 lines

Quoted 2 lines

Yeah, I think so. But, this is well into Al territory, and there might be a better way.

Well until we get that sorted out I will keep picking on i_sb.

Don't bother: labelling superblocks with process-specific data is always going to be unacceptable.

In order to avoid aliased superblocks, you would have to be able guarantee to be the sole owner of the data on the device that it refers to. You'd have to own the device in order to do that, in which case you are better off just labelling the device instead.

Now I do agree if I can set the information in vfsmount and not in the superblock it is probably better. But even with nfs mount superblock collapsing (which I almost understand) I don't see it as a real problem, as long as I could prevent the superblock from collapsing.

Quoted 4 lines · Eric W. Biederman

Now I do agree if I can set the information in vfsmount and not in the superblock it is probably better. But even with nfs mount superblock collapsing (which I almost understand) I don't see it as a real problem, as long as I could prevent the superblock from collapsing.

NFS is the least of your problems. You can only have one superblock for most local filesystems too and with good reason: imagine, for instance, the effect of having 2 different block allocators working on the same device.

Quoted 1 line · Trond Myklebust

NFS is the least of your problems. You can only have one superblock for most local filesystems too and with good reason: imagine, for instance, the effect of having 2 different block allocators working on the same device.

Let me try to explain the idea again.

Currently there is a global context in which we interpret uids. But different machines can have different global contexts.

Each filesystem to be sane needs to store uids from only one such context. For network filesystems typicall the context is extended to multiple machines so that everyone who mounts a filesystem will interpret a uid with the same meaning.

The idea of creating multiple a user id namespaces on a single machine creates multiple contexts for the interpretation of uid values on the same machine. Allowing a single id to refer to different users depending on the context in which it is interpreted.

I can think of no circumstance in which a single filesystem will have multiple contexts in which user id's will be interpreted. Nor can I think of a sane scenario in which that would occur.

Given the fact that we are referring to a global property of a filesystem why is it fundamentally a problem to put it in the superblock?

Here's a possible example:

I have one disk which I want to share between multiple virtualized instances for root filesystems. I bind-mount /onedisk/foo as the foo virtual machine's root and /onedisk/bar as the bar virtual machine's root. There should (must) be two interpretations of the linear UID space on that disk, one for the foo virtual machine, and one for the bar virtual machine. By allowing the administrator to determine UID namespace per-vfsmount, you make such an arrangement possible where it otherwise would not be.

With NFS and the proposed superblock-sharing patches (necessary for efficiency and other reasons I don't entirely understand), the situation is worse: A mount of server:/foo/bar on / in the bar virtual machine may get its superblock merged with a mount of server:/ foo/baz on / in the baz virtual machine. If it's efficient to merge those superblocks we should, and once again it's necessary to tie the UID namespace to the vfsmount, not the superblock.

Quoted 1 line · Kyle Moffett

With NFS and the proposed superblock-sharing patches (necessary for efficiency and other reasons I don't entirely understand), the situation is worse: A mount of server:/foo/bar on / in the bar virtual machine may get its superblock merged with a mount of server:/ foo/baz on / in the baz virtual machine. If it's efficient to merge those superblocks we should, and once again it's necessary to tie the UID namespace to the vfsmount, not the superblock.

I completely agree that pushing nameidata down into generic_permission where we can use per mount properties in our permission checks is ideal. The benefit I see is just a small increase in flexibility. So I don't really care either way.

Currently there are several additional flags that could benefit from a per vfsmount interpretation as well: nosuid, noexec, nodev, and readonly, how do we handle those?

noexec is on the vfsmount.
nosuid is on the vfsmount
nodev is on the vfsmount
readonly is not on the vfsmount.

The existing precedent is clearly in favor of putting this kind of information on the vfsmount. The read-only attribute seems to be the only hold out. If readonly has deep implications like no journal replay it makes sense to keep it per mount. Which indicates we could nose a nowrite option to express the per vfsmount property.

I hope the confusion has passed for Trond. My impression was he figured this was per process data so it didn't make sense any where near a filesystem, and the superblock was the last place it should be.

Currently there are several additional flags that could benefit from a per vfsmount interpretation as well: nosuid, noexec, nodev, and readonly, how do we handle those?

noexec is on the vfsmount.
nosuid is on the vfsmount
nodev is on the vfsmount
readonly is not on the vfsmount.

I hope the confusion has passed for Trond. My impression was he figured this was per process data so it didn't make sense any where near a filesystem, and the superblock was the last place it should be.

Quoted 4 lines · Eric W. Biederman

I hope the confusion has passed for Trond. My impression was he figured this was per process data so it didn't make sense any where near a filesystem, and the superblock was the last place it should be.

You are still using the wrong abstraction. Data that is not global to the entire machine has absolutely _no_ place being put into the superblock. It doesn't matter if it is process-specific, container-specific or whatever-else-specific, it will still be vetoed.

If your real problem is uid/gid mapping on top of generic filesystems, then have you looked into the *BSD solution of using a stackable filesystem (i.e. umapfs)?

Quoted 4 lines · Trond Myklebust

You are still using the wrong abstraction. Data that is not global to the entire machine has absolutely _no_ place being put into the superblock. It doesn't matter if it is process-specific, container-specific or whatever-else-specific, it will still be vetoed.

Sure, I have no problem with only global data, and filesystem specific data being in a super block. In this case my impression is that the data is at least arguably filesystem specific. filesystem-specific data is ok on the super block is it not?

Review

Quoted 4 lines · Eric W. Biederman

(quoted diff) +2 -1

-       if (current->fsuid == inode->i_uid)
+       if ((current->fsuid == inode->i_uid) &&
+               (current->nsproxy->user_ns == inode->i_sb->user_ns))
                mode >>= 6; 

I really don't think assigning a user namespace to a superblock is the right way to go. Seems to me like the _view_ into the filesystem is what you want to modify. That would seem to me to mean that each 'struct namespace' (filesystem namespace) or vfsmount would be assigned a corresponding user namespace, *not* the superblock.

Review

Quoted 4 lines

(quoted diff) +2 -1

-       if (current->fsuid == inode->i_uid)
+       if ((current->fsuid == inode->i_uid) &&
+               (current->nsproxy->user_ns == inode->i_sb->user_ns))
               mode >>= 6; 

I really don't think assigning a user namespace to a superblock is the right way to go. Seems to me like the _view_ into the filesystem is what you want to modify. That would seem to me to mean that each 'struct namespace' (filesystem namespace) or vfsmount would be assigned a corresponding user namespace, *not* the superblock.

Quoted 4 lines

Quoted 4 lines

(quoted diff) +2 -1

-       if (current->fsuid == inode->i_uid)
+       if ((current->fsuid == inode->i_uid) &&
+               (current->nsproxy->user_ns == inode->i_sb->user_ns))
               mode >>= 6;

Quoted 5 lines

I really don't think assigning a user namespace to a superblock is the right way to go. Seems to me like the _view_ into the filesystem is what you want to modify. That would seem to me to mean that each 'struct namespace' (filesystem namespace) or vfsmount would be assigned a corresponding user namespace, *not* the superblock.

I dislike this way either. We need an ability to have an access to container filesystems and data from the host.
such a strong checks break this.

Quoted 10 lines · Serge E. Hallyn

Quoted 9 lines · Eric W. Biederman

Quoted 6 lines · Dave Hansen

Quoted 3 lines · Eric W. Biederman

I think for filesystems like /proc and /sys that there will normally be problems. However many of those problems can be rationalized away as a reasonable optimization, or are not immediately apparent.

Could you talk about some of these problems?

Quoted 4 lines

Quoted 2 lines

Already mentioned but. rw permissions on sensitive files are for uid == 0. No capability checks are performed.

As Herbert (IIRC) pointed out that could/should be fixed.

Capabilities have always fitted badly in with the normal unix permissions.

So if we have a solution that works nicely with normal unix permissions we will have a nice general solution, that is easy for people to understand.

What I am talking about is making a small tweak to the permission checking as below. Why do you keep avoiding even considering it?

Quoted 1 line · Eric W. Biederman

Capabilities have always fitted badly in with the normal unix permissions.

Well they're not supposed to fit in.

If we keep permchecks as uid==0 on files which invoke kernel callbacks, then we can only say once what root is allowed to do. If we make them capability checks, then for differnet uses of namespaces we can have them do different things. For instance if we're making a separate user namespace for a checkpoint/restart purpose, we might want root to retain more privs than if we're making a vserver.

Look I just have to keep responding because you keep provoking :), but I'm looking at other code and don't even know which entries we're talking about. If when I get to looking at them I find they really should be done by capabilities, I'll submit a patch and we can argue then.

Quoted 14 lines · Serge E. Hallyn

Quoted 2 lines · Eric W. Biederman

Capabilities have always fitted badly in with the normal unix permissions.

Well they're not supposed to fit in.

If we keep permchecks as uid==0 on files which invoke kernel callbacks, then we can only say once what root is allowed to do. If we make them capability checks, then for differnet uses of namespaces we can have them do different things. For instance if we're making a separate user namespace for a checkpoint/restart purpose, we might want root to retain more privs than if we're making a vserver.

Quoted 5 lines

Look I just have to keep responding because you keep provoking :), but I'm looking at other code and don't even know which entries we're talking about. If when I get to looking at them I find they really should be done by capabilities, I'll submit a patch and we can argue then.

Capabilities are not a single fundamental privilege set and they

don't interact at all nicely with virtualization. If we're going to

do this properly we need to divide capabilities up into different sets applied to different objects. For example, the CAP_DAC_OVERRIDE capability should _really_ be per (PID,vfsmount) pair, although that would probably be exceptionally inefficient, so as an optimization we could make it per (PID,target_uid_ns) pair. That maps very conveniently to the kernel keyring system, where we can make a "uid" keytype indexed by target_uid_ns and containing three things: A process-manipulation UID (think euid), a file-manipulation UID (think fsuid), and a set of per-uid-ns capabilities. Similar mappings should be set up for most of the other capabilities. Normal cap_set and cap_get and capable() calls on those particular capabilities should look up and modify the "uid" key associated with the current-

Quoted 1 line

nsproxy->uidns namespace, and extra calls should be added to modify

capabilities with respect to specific UID namespaces.

Here's a list of capabilities that should probably be in each "uid" key:
CAP_CHOWN
CAP_DAC_OVERRIDE
CAP_DAC_READ_SEARCH
CAP_FOWNER
CAP_FSETID
CAP_FS_MASK
CAP_SETGID
CAP_SETUID
CAP_LINUX_IMMUTABLE
CAP_IPC_OWNER

Cheers,
Kyle Moffett

Quoted 4 lines · Eric W. Biederman

"Serge E. Hallyn" <[email protected]> writes:

Capabilities have always fitted badly in with the normal unix permissions.

Well they're not supposed to fit in.

If we keep permchecks as uid==0 on files which invoke kernel callbacks, then we can only say once what root is allowed to do. If we make them capability checks, then for differnet uses of namespaces we can have them do different things. For instance if we're making a separate user namespace for a checkpoint/restart purpose, we might want root to retain more privs than if we're making a vserver.

Look I just have to keep responding because you keep provoking :), but I'm looking at other code and don't even know which entries we're talking about. If when I get to looking at them I find they really should be done by capabilities, I'll submit a patch and we can argue then.

Quoted 6 lines

So if we have a solution that works nicely with normal unix permissions we will have a nice general solution, that is easy for people to understand.

What I am talking about is making a small tweak to the permission checking as below. Why do you keep avoiding even considering it?

Not only don't I avoid considering it, I thought I'd even suggested it a while ago :)

It sounds good to me.

Already mentioned but. rw permissions on sensitive files are for uid == 0. No capability checks are performed.

Quoted 7 lines · Dave Hansen

Quoted 3 lines · Eric W. Biederman

Maybe. I really think the sane semantics are in a different uid namespace. So you can't assumes uids are the same. Otherwise you can't handle open file descriptors or files passed through unix domain sockets.

Eric, could you explain this a little bit more? I'm not sure I understand the details of why this is a problem?

Very simply.

In the presence of a user namespace.
All comparisons of a user equality need to be of the tuple (user namespace, user id). Any comparison that does not do that is an optimization.

Because you can have access to files created in another user namespace it is very unlikely that optimization will apply very frequently. The easy scenario to get access to a file descriptor from another context is to consider unix domain sockets.

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Dave Hansen

Quoted 3 lines · Eric W. Biederman

Maybe. I really think the sane semantics are in a different uid namespace. So you can't assumes uids are the same. Otherwise you can't handle open file descriptors or files passed through unix domain sockets.

Quoted 7 lines

Quoted 2 lines

Eric, could you explain this a little bit more? I'm not sure I understand the details of why this is a problem?

Very simply.

In the presence of a user namespace.
All comparisons of a user equality need to be of the tuple (user namespace,

user id).

Quoted 4 lines

Any comparison that does not do that is an optimization.

Because you can have access to files created in another user namespace it is very unlikely that optimization will apply very frequently. The easy

scenario

Quoted 2 lines

to get access to a file descriptor from another context is to consider unix domain sockets.

What does that have to do with uids? If you receive an fd, uids don't matter in any case. The only permission checks which happen are LSM hooks, which should be uid-agnostic.

Quoted 24 lines · Serge E. Hallyn

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Dave Hansen

Quoted 3 lines · Eric W. Biederman

Maybe. I really think the sane semantics are in a different uid namespace. So you can't assumes uids are the same. Otherwise you can't handle open file descriptors or files passed through unix domain sockets.

Quoted 7 lines

Quoted 2 lines

Eric, could you explain this a little bit more? I'm not sure I understand the details of why this is a problem?

Very simply.

In the presence of a user namespace.
All comparisons of a user equality need to be of the tuple (user namespace,

user id).

Quoted 4 lines

Any comparison that does not do that is an optimization.

Because you can have access to files created in another user namespace it is very unlikely that optimization will apply very frequently. The easy

scenario

Quoted 2 lines

to get access to a file descriptor from another context is to consider unix domain sockets.

Quoted 3 lines

What does that have to do with uids? If you receive an fd, uids don't matter in any case. The only permission checks which happen are LSM hooks, which should be uid-agnostic.

You are guest uid 0. You get a directory file descriptor from another namespace. You call fchdir.

If you permission checks are not (user namespace, uid) what can't you do?

Quoted 1 line · Eric W. Biederman

If you permission checks are not (user namespace, uid) what can't you do?

File descripters can only be passed over a unix socket, right?

So this seems to fall into the same "userspace should set things up sanely" argument you've brought up before.

Don't get me wrong though - the idea of using in-kernel keys as cross-namespace uid's is definately interesting.

Quoted 4 lines · Serge E. Hallyn

Quoted 1 line · Eric W. Biederman

If you permission checks are not (user namespace, uid) what can't you do?

File descripters can only be passed over a unix socket, right?

No. You can use /proc to do the same thing. You can inherit

file descriptors, etc. This isn't a door you can just close and ignore. It is too easy to do this to assume you have closed every possible way to get a descriptor from outside of ``container''.

Suppose you have user fred uid 1000 outside of any containers, and you have user joe uid 1000 inside user uid namespace. If you don't make your permission checks (user namespace, uid) fred can do terrible

If I we don't do the expanded permission checks the only alternative is to check to see if every object is in our ``container'' at every access. That isn't something I want to do.

I don't intend to partition objects just partition object look ups by name. Which means that if you very carefully setup your initial process you will never be able to find an object outside of your namespace. But the kernel never should assume user space has done that.

Quoted 2 lines

So this seems to fall into the same "userspace should set things up sanely" argument you've brought up before.

For using it yes. But not for correct kernel operation.

Quoted 2 lines

Don't get me wrong though - the idea of using in-kernel keys as cross-namespace uid's is definately interesting.

That is their role in the kernel.

A flavor of key to handle uid
mapping needs to be added, but that is all.

Quoted 8 lines · Eric W. Biederman

Quoted 4 lines · Serge E. Hallyn

Quoted 1 line · Eric W. Biederman

If you permission checks are not (user namespace, uid) what can't you do?

File descripters can only be passed over a unix socket, right?

No. You can use /proc to do the same thing. You can inherit

How?

Quoted 7 lines

file descriptors, etc. This isn't a door you can just close and ignore. It is too easy to do this to assume you have closed every possible way to get a descriptor from outside of ``container''.

Suppose you have user fred uid 1000 outside of any containers, and you have user joe uid 1000 inside user uid namespace. If you don't make your permission checks (user namespace, uid) fred can do terrible

Only if user fred can reach user joe's files.

Quoted 3 lines

If I we don't do the expanded permission checks the only alternative is to check to see if every object is in our ``container'' at every access. That isn't something I want to do.

Ditto.

Quoted 1 line

I don't intend to partition objects just partition object look ups by name.

Quoted 3 lines

Which means that if you very carefully setup your initial process you will never be able to find an object outside of your namespace. But the kernel never should assume user space has done that.

Are you contradicting yourself here?

Quoted 4 lines

Quoted 2 lines

So this seems to fall into the same "userspace should set things up sanely" argument you've brought up before.

For using it yes. But not for correct kernel operation.

Well if we say the kernel controls files (barring LSMs) based on simple uids, then that is correct kernel operation :)

In other words we're not letting the kernel do anything it isn't supposed to do.

Quoted 4 lines

Quoted 2 lines

Don't get me wrong though - the idea of using in-kernel keys as cross-namespace uid's is definately interesting.

That is their role in the kernel.

They have more roles than that...

I phrased it the way I did to point out we shouldn't need to be using ecryptfs - which uses the keyring to store actual encryptions keys - to do this.

Quoted 2 lines

A flavor of key to handle uid
mapping needs to be added, but that is all.

How can that be all? How do we represent this on the filesystem then?

We can't store (namespace, uid) because we presumably dont' have actual external unique ids for a namespace. So we really will need to provide global uids, and store those in the keys (and with the files). So now 3475276bc0dcd9cc501ba9bb7f12683f1b867066 is my uid no matter where I am, for instance.

/proc/<pid>/fd/...
/proc/<pid>/exe
/proc/<pid>/cwd

It isn't quite the same as you are actually opening a second copy of the file descriptor but the essence is the same.

Quoted 6 lines · Eric W. Biederman

/proc/<pid>/fd/...
/proc/<pid>/exe
/proc/<pid>/cwd

It isn't quite the same as you are actually opening a second copy of the file descriptor but the essence is the same.

Last I checked, those were symlinks and didn't work for things like deleted files. Am I wrong?

Quoted 8 lines · Eric W. Biederman

Quoted 6 lines

/proc/<pid>/fd/...
/proc/<pid>/exe
/proc/<pid>/cwd

It isn't quite the same as you are actually opening a second copy of the file descriptor but the essence is the same.

Quoted 2 lines

Last I checked, those were symlinks and didn't work for things like deleted files. Am I wrong?

Yes. They are not really symlinks.

Wanting to have an executable that was deleted after it was done executing. I wrote it to a file. opened it, unlinked it, set close on exec, and the exec'd it with /proc/self/fd/N.

Quoted 8 lines · Eric W. Biederman

Quoted 8 lines · Eric W. Biederman

Quoted 6 lines

/proc/<pid>/fd/...
/proc/<pid>/exe
/proc/<pid>/cwd

It isn't quite the same as you are actually opening a second copy of the file descriptor but the essence is the same.

Quoted 8 lines

Quoted 2 lines

Last I checked, those were symlinks and didn't work for things like deleted files. Am I wrong?

Yes. They are not really symlinks.

Wanting to have an executable that was deleted after it was done executing. I wrote it to a file. opened it, unlinked it, set close on exec, and the exec'd it with /proc/self/fd/N.

Well, on one hand, it makes checkpoints with deleted files easier ;)

Now that I'm actually looking at the code, isn't proc_fd_access_allowed()'s permission just derived from ptrace permissions? It doesn't seem to involve uids directly at all!

Quoted 6 lines · Eric W. Biederman

Quoted 2 lines

I think user namespace should be unshared with filesystem. if not, the user/admin should know what is doing.

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem.

ok. so once you're in such a user namespace, you can't unshare from it without loosing access to all your files ?

Quoted 2 lines

Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

well, this is what is currently done without user namespaces.

Quoted 9 lines

Quoted 4 lines

Quoted 2 lines

I believe some of the key infrastructure which is roughly kerberos authentication tokens could be used for this purpose.

please elaborate ? i'm not sure to understand why you want to use the keys to map users.

keys are essentially security credentials for something besides the local kernel. Think kerberos tickets. That makes the keys the obvious place to say what uid you are in a different user namespace and similar things.

what about performance ? wouldn't that slow the checking ?

Quoted 6 lines

Quoted 4 lines

keys are essentially security credentials for something besides the local kernel. Think kerberos tickets. That makes the keys the obvious place to say what uid you are in a different user namespace and similar things.

what about performance ? wouldn't that slow the checking ?

It needs to be looked at, but it shouldn't slow the same namespace case,

and permission checking is largely a slow path issue. So a little overhead at open time is preferred to overhead after you get the file open.

Quoted 5 lines · Eric W. Biederman

Quoted 5 lines

Quoted 4 lines

keys are essentially security credentials for something besides the local kernel. Think kerberos tickets. That makes the keys the obvious place to say what uid you are in a different user namespace and similar things.

Quoted 4 lines

Quoted 1 line

what about performance ? wouldn't that slow the checking ?

It needs to be looked at, but it shouldn't slow the same namespace case,

How so? The processesing is the same.

Quoted 3 lines

and permission checking is largely a slow path issue. So a little overhead at open time is preferred to overhead after you get the file open.

Unsure which approach has overhead after file open...

Quoted 27 lines · Cedric Le Goater

Quoted 15 lines · Eric W. Biederman

Quoted 6 lines · Cedric Le Goater

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

Quoted 6 lines

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

Quoted 3 lines

It is completely the wrong thing for a the root_user to span multiple namespaces as you describe. It is important for uid 0 in other namespaces to not have the privileges of the root_user. That is half the point.

ok good. that's what i thought also.

Quoted 4 lines

Too many files in sysfs and proc don't require caps but instead simply limit things to uid 0. Having a separate uid 0 in the different namespaces instantly makes all of these files inaccessible, and keeps processes from doing something bad.

Quoted 2 lines

but in order to be useful, the uid 0 in other namespaces will need to have some capabilities.

Yes. It is useful for uid 0 in other namespaces to have some capabilities. But that is just a matter of giving another user some additional capabilities. That mechanism may still work but it should not be namespace specific magic there. The trick I guess is which capabilities a setuid binary for the other root user gets.

One thing to be careful about here is that, at least as I envision it until setresuid is called your user does not change even when you unshare your user namespace.

Quoted 6 lines

Quoted 5 lines

To a filesystem a uid does not share a uid namespace with the only things that should be accessible are those things that are readable/writeable
by everyone. Unless the filesystem has provisions for storing multiple
uid namespaces not files should be able to be created. Think NFS root squash.

Quoted 2 lines

I think user namespace should be unshared with filesystem. if not, the user/admin should know what is doing.

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem. Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

Quoted 2 lines

now, we could work on extending it to support fine grain user namespace which i think can done on top of this first patch.

Yes. Your patch does lay some interesting foundation work. But we must not merge it upstream until we have a complete patchset that handles all of the user namespace issues.

Quoted 9 lines

Quoted 3 lines

I think the key infrastructure needs to be looked at here as well.

There needs to be a user namespace association for mounted filesystems.

yes you could expect that to check the i_uid against fsuid but should we enforce it completely ?

we already have an issue today with a simple NFS mount on 2 hosts with different user mapping. namespace can't fix all issues.

Yes. This is an existing problem, which we have just escalated the frequency of immensely if we are doing user namespaces. The normal solution is to put everyone on the network in a single user id administration domain with ldap or NIS.

However that is avoiding the problem, and having multiple user id domains is the point of a user id namespace. If we escalate the problem we should solve it.

keys are essentially security credentials for something besides the local kernel. Think kerberos tickets. That makes the keys the obvious place to say what uid you are in a different user namespace and similar things.

Quoted 29 lines · Eric W. Biederman

Quoted 27 lines · Cedric Le Goater

Quoted 15 lines · Eric W. Biederman

Quoted 6 lines · Cedric Le Goater

This patch adds the user namespace.

Basically, it allows a process to unshare its user_struct table, resetting at the same time its own user_struct and all the associated accounting.

Quoted 6 lines

For the moment, the root_user is added to the new user namespace when it is cloned. An alternative behavior would be to let the system allocate a new user_struct(0) in each new user namespace. However, these 0 users would not have the privileges of the root_user and it would be necessary to work on the process capabilities to give them some permissions.

Quoted 3 lines

It is completely the wrong thing for a the root_user to span multiple namespaces as you describe. It is important for uid 0 in other namespaces to not have the privileges of the root_user. That is half the point.

ok good. that's what i thought also.

Quoted 4 lines

Too many files in sysfs and proc don't require caps but instead simply limit things to uid 0. Having a separate uid 0 in the different namespaces instantly makes all of these files inaccessible, and keeps processes from doing something bad.

Quoted 8 lines

Quoted 2 lines

but in order to be useful, the uid 0 in other namespaces will need to have some capabilities.

Yes. It is useful for uid 0 in other namespaces to have some capabilities. But that is just a matter of giving another user some additional capabilities. That mechanism may still work but it should not be namespace specific magic there. The trick I guess is which capabilities a setuid binary for the other root user gets.

Agreed. Any ideas for how to specify this? In a sane way? I suppose it could be a part of forking off the user namespace. No idea what interface we'd want to use. Perhaps root user in the child namespace by default gets all the caps as the root user, and is expected to drop what it doesn't need?

int cap_bprm_set_security (struct linux_binprm *bprm)

{
	/* Copied from fs/exec.c:prepare_binprm. */

	/* We don't have VFS support for capabilities yet */
	cap_clear (bprm->cap_inheritable);
	cap_clear (bprm->cap_permitted);
	cap_clear (bprm->cap_effective);

	/*  To support inheritance of root-permissions and suid-root
	 *  executables under compatibility mode, we raise all three
	 *  capability sets for the file.
	 *
	 *  If only the real uid is 0, we only raise the inheritable
	 *  and permitted sets of the executable file.
	 */

	if (!issecure (SECURE_NOROOT)) {
		if (bprm->e_uid == 0 || current->uid == 0) {

			cap_set_full (bprm->cap_inheritable);
			cap_set_full (bprm->cap_permitted);
		}
		if (bprm->e_uid == 0)
			cap_set_full (bprm->cap_effective);
	}
	return 0;
}

Quoted 4 lines

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem. Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

But, when I insert a usb keychain disk into my laptop, that fs assumes the uids on it's fs are the same as uids on my laptop...

Solving that problem is interesting, but may be something to work with a much wider community on. I.e. the cifs and nifs folks. I haven't even googled to see what they say about it.

Quoted 3 lines

Yes. Your patch does lay some interesting foundation work. But we must not merge it upstream until we have a complete patchset that handles all of the user namespace issues.

Don't think Cedric expected this to be merged :) Just to start discussion, which it certainly did...

If we're going to talk about keys (which I'd like to) I think we need to decide whether we are just using them as an easy wider-than-uid identifier, or if we actually need cryptographic keys to prevent "identity theft" (heheh). I don't know that we need the latter for anything, but of course if we're going to try for a more general solution, then we do.

Quoted 5 lines · Serge E. Hallyn

Quoted 4 lines

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem. Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

Quoted 2 lines

But, when I insert a usb keychain disk into my laptop, that fs assumes the uids on it's fs are the same as uids on my laptop...

I agree that setting the fs_user_namespace at mount time is fine. However when we use a mount that a process in another user namespace we need to not assume the uids are the same.

Do you see the difference?

Quoted 2 lines

much wider community on. I.e. the cifs and nifs folks. I haven't even googled to see what they say about it.

Yes.

Quoted 4 lines

Quoted 3 lines

Yes. Your patch does lay some interesting foundation work. But we must not merge it upstream until we have a complete patchset that handles all of the user namespace issues.

Quoted 2 lines

Don't think Cedric expected this to be merged :) Just to start discussion, which it certainly did...

If we could have [RFC] in front of these proof of concept patches it would clear up a lot of confusion.

Quoted 6 lines

If we're going to talk about keys (which I'd like to) I think we need to decide whether we are just using them as an easy wider-than-uid identifier, or if we actually need cryptographic keys to prevent "identity theft" (heheh). I don't know that we need the latter for anything, but of course if we're going to try for a more general solution, then we do.

Actually I was thinking something as mundane as a mapping table. This uid in this namespace equals that uid in that other namespace.

Quoted 9 lines · Eric W. Biederman

Quoted 7 lines · Serge E. Hallyn

Quoted 4 lines

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem. Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

But, when I insert a usb keychain disk into my laptop, that fs assumes the uids on it's fs are the same as uids on my laptop...

Quoted 5 lines

I agree that setting the fs_user_namespace at mount time is fine. However when we use a mount that a process in another user namespace we need to not assume the uids are the same.

Do you see the difference?

Aaah - so you don't want to store this on the fs. So this is actually like what I had mentioned many many emails ago?

Quoted 2 lines

Actually I was thinking something as mundane as a mapping table. This uid in this namespace equals that uid in that other namespace.

I see.

That's also what I was imagining earlier, but it seems crass somehow. I'd almost prefer to just tag a mount with a user namespace implicitly, and only allow the mounter to say 'do' or 'don't' allow this to be read by users in another namespace. Then in the 'don't' case, user joe [1000] can't read files belonging to user jack [1000] in another namespace. It's stricter, but clean.

But whether we do mapping tables or simple isolation, I do still like the idea of pursuing the use of the keystore for global uids.

Quoted 1 line · Eric W. Biederman

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem. Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

But, when I insert a usb keychain disk into my laptop, that fs assumes the uids on it's fs are the same as uids on my laptop...

Solving that problem is interesting, but may be something to work with a much wider community on. I.e. the cifs and nifs folks. I haven't even googled to see what they say about it.

Quoted 6 lines · Serge E. Hallyn

Quoted 4 lines · Eric W. Biederman

No. The uids in a filesystem are interpreted in some user namespace context. We can discover that context at the first mount of the filesystem. Assuming the uids on a filesystem are the same set of uids your process is using is just wrong.

Quoted 6 lines

But, when I insert a usb keychain disk into my laptop, that fs assumes the uids on it's fs are the same as uids on my laptop...

Solving that problem is interesting, but may be something to work with a much wider community on. I.e. the cifs and nifs folks. I haven't even googled to see what they say about it.

IMHO filesystems _and_ processes should be primary objects in a UID namespace. This would make it possible to solve the usb-key problems _and_ the user-mounted FUSE problems. If "ns0" is the boot uid namespace, then put the freshly mounted USB key in a new "ns1" (names just for convenience). All the user processes would continue to be in ns0, but with the kernel keyring system you could create a new "uid" keytype and give the logged in user (ns0,user_uid) a user-key with (ns1,0*). If you added bits to the user-keys to represent the equivalent of CAP_DAC_OVERRIDE/CAP_CHOWN/etc for that process and UID namespace, then the user could do anything to any file on their USB key, even change ownership, without disrupting the rest of the system. Likewise, if you did that for user FUSE filesystems, then suid binaries would not be able to get themselves into trouble in exploitive FUSE infinitely-recursive monstrosities.

This patch forbids the use of the unshare() syscall on ipc namespaces.

The purpose of this restriction is to protect the system from inconsistencies when the namespace is unshared. e.g. shared memory ids will be removed but not the memory mappings, semaphore ids will be removed but the semundos not cleared.

Signed-off-by Cedric Le Goater <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Pavel Emelianov <[email protected]>

Cc Kirill Korotaev <[email protected]>

Cc Andrey Savochkin <[email protected]>

Cc Eric W. Biederman <[email protected]>

Cc Herbert Poetzl <[email protected]>

Cc Sam Vilain <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Dave Hansen <[email protected]>

---
 kernel/fork.c |   23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

Index: 2.6.18-rc1-mm1/kernel/fork.c
===================================================================

kernel/fork.c +5 -19

@@ -1604,7 +1604,6 @@ asmlinkage long sys_unshare(unsigned lon
 	struct sem_undo_list *new_ulist = NULL;
 	struct nsproxy *new_nsproxy = NULL, *old_nsproxy = NULL;
 	struct uts_namespace *uts, *new_uts = NULL;
-	struct ipc_namespace *ipc, *new_ipc = NULL;
 
 	check_unshare_flags(&unshare_flags);
 

@@ -1612,12 +1611,12 @@ asmlinkage long sys_unshare(unsigned lon
 	err = -EINVAL;
 	if (unshare_flags & ~(CLONE_THREAD|CLONE_FS|CLONE_NEWNS|CLONE_SIGHAND|
 				CLONE_VM|CLONE_FILES|CLONE_SYSVSEM|
-				CLONE_NEWUTS|CLONE_NEWIPC))
+				CLONE_NEWUTS))
 		goto bad_unshare_out;
 
 	/* Also return -EINVAL for all unsharable namespaces. May be a
 	 * -EACCES would be more appropriate ? */
-	if (unshare_flags & CLONE_NEWUSER)
+	if (unshare_flags & (CLONE_NEWUSER|CLONE_NEWIPC))
 		goto bad_unshare_out;
 
 	if ((err = unshare_thread(unshare_flags)))

@@ -1636,20 +1635,18 @@ asmlinkage long sys_unshare(unsigned lon
 		goto bad_unshare_cleanup_fd;
 	if ((err = unshare_utsname(unshare_flags, &new_uts)))
 		goto bad_unshare_cleanup_semundo;
-	if ((err = unshare_ipcs(unshare_flags, &new_ipc)))
-		goto bad_unshare_cleanup_uts;
 
-	if (new_ns || new_uts || new_ipc) {
+	if (new_ns || new_uts) {
 		old_nsproxy = current->nsproxy;
 		new_nsproxy = dup_namespaces(old_nsproxy);
 		if (!new_nsproxy) {
 			err = -ENOMEM;
-			goto bad_unshare_cleanup_ipc;
+			goto bad_unshare_cleanup_uts;
 		}
 	}
 
 	if (new_fs || new_ns || new_sigh || new_mm || new_fd || new_ulist ||
-				new_uts || new_ipc) {
+				new_uts) {
 
 		task_lock(current);
 

@@ -1697,22 +1694,12 @@ asmlinkage long sys_unshare(unsigned lon
 			new_uts = uts;
 		}
 
-		if (new_ipc) {
-			ipc = current->nsproxy->ipc_ns;
-			current->nsproxy->ipc_ns = new_ipc;
-			new_ipc = ipc;
-		}
-
 		task_unlock(current);
 	}
 
 	if (new_nsproxy)
 		put_nsproxy(new_nsproxy);
 
-bad_unshare_cleanup_ipc:
-	if (new_ipc)
-		put_ipc_ns(new_ipc);
-
 bad_unshare_cleanup_uts:
 	if (new_uts)
 		put_uts_ns(new_uts);
 
--