From: Aleksa Sarai <asarai@suse.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tejun Heo <tj@kernel.org>, Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
Aditya Kali <adityakali@google.com>,
Chris Wilson <chris@chris-wilson.co.uk>
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
Christian Brauner <cbrauner@suse.de>,
Aleksa Sarai <asarai@suse.de>,
dev@opencontainers.org
Subject: [PATCH v1 2/3] cgroup: allow for unprivileged subtree management
Date: Tue, 19 Jul 2016 02:18:15 +1000 [thread overview]
Message-ID: <20160718161816.13040-3-asarai@suse.de> (raw)
In-Reply-To: <20160718161816.13040-1-asarai@suse.de>
Use the new custom ->permission hook to allow unprivileged processes to
mkdir new sub-cgroup directories of the root_cset of their current
cgroup namespace. No process outside of the cgroup namespace (or in a
sub-namespace) has this ability, and thus a process must have sufficient
privileges to setns to a cgroup namespace in order to create cgroups in
a cgroup they are not currently residing in.
Only privileged processes in the user namespace pinned to the cgroup
namespace have this new ability. This further restricts any oddness from
happening with the creation of many cgroups which the process cannot
effectively join.
This change only applies to the default hierarchy, as cgroupv1 cgroups
are not necessarily hierarchical (thus allowing the creating of new
sub-cgroups would allow for circumvention of cgroup limits). However,
since cgroupv2 cgroups are strictly hierarchical as a design constraint
this is possible.
It should be noted that cgroupv2 also has attaching restrictions that
make this process safe against two complicit processes from migrating
a process to the less restrictive cgroup of the two.
Cc: dev@opencontainers.org
Signed-off-by: Aleksa Sarai <asarai@suse.de>
---
kernel/cgroup.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 8647f3112f5c..4559baa7eabd 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5490,6 +5490,67 @@ static int cgroup_rmdir(struct kernfs_node *kn)
return ret;
}
+/*
+ * We have specific rules when deciding if a process can write to a cgroup
+ * directory, based on their current state inside cgroupns.
+ */
+static int cgroup_permission(struct inode *inode, struct kernfs_node *kn,
+ int mask)
+{
+ int ret;
+ struct cgroup *cgroup;
+ struct cgroup_namespace *cgroupns;
+
+ /*
+ * First, compute the generic_permission return value. In most cases
+ * this will succeed and we can also avoid duplicating this code.
+ */
+
+ cgroup = kn->priv;
+ cgroup_get(cgroup);
+
+ /* First, try the generic method which should work in most cases. */
+ ret = generic_permission(inode, mask);
+
+ /* If the generic check succeeded, then we're all good. */
+ if (!ret)
+ goto out_put_cgroup;
+
+ /* We're only interested in cgroup directories. */
+ if (kernfs_type(kn) != KERNFS_DIR)
+ goto out_put_cgroup;
+
+ /* ... and in may_create() operations only. */
+ if ((mask & (MAY_WRITE | MAY_EXEC)) != (MAY_WRITE | MAY_EXEC))
+ goto out_put_cgroup;
+
+ /*
+ * This only applies for cgroups on the default hierarchy, as cgroupv1
+ * was not truly hierarchical this operation was not safe.
+ */
+ if (!cgroup_on_dfl(cgroup))
+ goto out_put_cgroup;
+
+ cgroupns = current->nsproxy->cgroup_ns;
+ get_cgroup_ns(cgroupns);
+
+ ret = -EPERM;
+ if (cgroupns->root_cset->dfl_cgrp == cgroup) {
+ /*
+ * Check CAP_SYS_ADMIN, to make sure that unprivileged
+ * processes inside a cgroup namespace they don't "own" don't
+ * get any special treatment.
+ */
+ if (ns_capable(cgroupns->user_ns, CAP_SYS_ADMIN))
+ ret = 0;
+ }
+
+ put_cgroup_ns(cgroupns);
+out_put_cgroup:
+ cgroup_put(cgroup);
+ return ret;
+}
+
static struct kernfs_syscall_ops cgroup_kf_syscall_ops = {
.remount_fs = cgroup_remount,
.show_options = cgroup_show_options,
@@ -5497,6 +5558,7 @@ static struct kernfs_syscall_ops cgroup_kf_syscall_ops = {
.rmdir = cgroup_rmdir,
.rename = cgroup_rename,
.show_path = cgroup_show_path,
+ .permission = cgroup_permission,
};
static void __init cgroup_init_subsys(struct cgroup_subsys *ss, bool early)
--
2.9.0
next prev parent reply other threads:[~2016-07-18 16:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 16:18 [PATCH v1 0/3] cgroup: allow for unprivileged management Aleksa Sarai
2016-07-18 16:18 ` [PATCH v1 1/3] kernfs: add support for custom per-sb permission hooks Aleksa Sarai
2016-07-18 16:18 ` Aleksa Sarai [this message]
2016-07-20 15:45 ` [PATCH v1 2/3] cgroup: allow for unprivileged subtree management Tejun Heo
2016-07-20 22:59 ` Aleksa Sarai
2016-07-18 16:18 ` [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants Aleksa Sarai
2016-07-20 15:51 ` Tejun Heo
2016-07-20 22:58 ` Aleksa Sarai
2016-07-20 23:02 ` Tejun Heo
2016-07-20 23:18 ` Aleksa Sarai
2016-07-20 23:19 ` Tejun Heo
2016-07-21 7:49 ` Aleksa Sarai
2016-07-21 14:33 ` Serge E. Hallyn
2016-07-21 14:37 ` Aleksa Sarai
2016-07-21 15:01 ` Tejun Heo
2016-07-21 15:09 ` Serge E. Hallyn
2016-07-21 14:51 ` James Bottomley
2016-07-21 14:59 ` Tejun Heo
2016-07-21 15:07 ` Aleksa Sarai
2016-07-21 15:04 ` Tejun Heo
2016-07-21 14:52 ` Tejun Heo
2016-07-21 15:04 ` James Bottomley
2016-07-21 15:07 ` Tejun Heo
2016-07-21 15:16 ` James Bottomley
2016-07-21 15:26 ` Tejun Heo
2016-07-21 15:34 ` James Bottomley
2016-07-21 15:50 ` Tejun Heo
2016-07-21 18:16 ` James Bottomley
2016-07-21 21:06 ` Tejun Heo
2016-07-22 8:30 ` Aleksa Sarai
2016-07-25 18:38 ` Tejun Heo
2016-07-25 22:54 ` Serge E. Hallyn
2016-07-22 8:24 ` Aleksa Sarai
2016-07-25 18:44 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160718161816.13040-3-asarai@suse.de \
--to=asarai@suse.de \
--cc=adityakali@google.com \
--cc=cbrauner@suse.de \
--cc=cgroups@vger.kernel.org \
--cc=chris@chris-wilson.co.uk \
--cc=dev@opencontainers.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=serge.hallyn@ubuntu.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®