userns: Allow unprivileged users to create user namespaces.

Now that we have been through every permission check in the kernel
having uid == 0 and gid == 0 in your local user namespace no
longer adds any special privileges.  Even having a full set
of caps in your local user namespace is safe because capabilies
are relative to your local user namespace, and do not confer
unexpected privileges.

Over the long term this should allow much more of the kernels
functionality to be safely used by non-root users.  Functionality
like unsharing the mount namespace that is only unsafe because
it can fool applications whose privileges are raised when they
are executed.  Since those applications have no privileges in
a user namespaces it becomes safe to spoof and confuse those
applications all you want.

Those capabilities will still need to be enabled carefully because
we may still need things like rlimits on the number of unprivileged
mounts but that is to avoid DOS attacks not to avoid fooling root
owned processes.

Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

diff --git a/kernel/fork.c b/kernel/fork.c
index 811ffbad78899e66baf80509f53a1911b38f3f84..8c29abb19014df2c1f330b04d3253eb63fc1aee4 100644 (file)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1569,14 +1569,6 @@ long do_fork(unsigned long clone_flags,
                if (clone_flags & (CLONE_THREAD|CLONE_PARENT))
                        return -EINVAL;
        }
-       if (clone_flags & CLONE_NEWUSER) {
-               /* hopefully this check will go away when userns support is
-                * complete
-                */
-               if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SETUID) ||
-                               !capable(CAP_SETGID))
-                       return -EPERM;
-       }
 
        /*
         * Determine whether and which event to report to ptracer.  When