From: Andrew Morton <akpm@linux-foundation.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
daniel@hozac.com, lizf@cn.fujitsu.com,
Pavel Emelyanov <xemul@openvz.org>, Greg KH <greg@kroah.com>
Subject: Re: [PATCH 1/1] cgroups: implement device whitelist (v6)
Date: Thu, 27 Mar 2008 02:04:03 -0700 [thread overview]
Message-ID: <20080327020403.5547e43f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080326180543.GA27709@sergelap.austin.ibm.com>
On Wed, 26 Mar 2008 13:05:43 -0500 "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> (This is identical to the version I sent on Mar 19 in response to
> the comments by Daniel Hokka Zakrisson, which are the last
> comments I've gotten.)
>
> Implement a cgroup to track and enforce open and mknod restrictions on device
> files. A device cgroup associates a device access whitelist with each
> cgroup. A whitelist entry has 4 fields. 'type' is a (all), c (char), or
> b (block). 'all' means it applies to all types and all major and minor
> numbers. Major and minor are either an integer or * for all.
> Access is a composition of r (read), w (write), and m (mknod).
>
> The root device cgroup starts with rwm to 'all'. A child devcg gets
> a copy of the parent. Admins can then remove devices from the
> whitelist or add new entries. A child cgroup can never receive a
> device access which is denied its parent. However when a device
> access is removed from a parent it will not also be removed from the
> child(ren).
>
> An entry is added using devices.allow, and removed using
> devices.deny. For instance
>
> echo 'c 1:3 mr' > /cgroups/1/devices.allow
>
> allows cgroup 1 to read and mknod the device usually known as
> /dev/null. Doing
>
> echo a > /cgroups/1/devices.deny
>
> will remove the default 'a *:* mrw' entry.
>
> CAP_SYS_ADMIN is needed to change permissions or move another task
> to a new cgroup. A cgroup may not be granted more permissions than
> the cgroup's parent has. Any task can move itself between cgroups.
> This won't be sufficient, but we can decide the best way to
> adequately restrict movement later.
The above should be in Documentation/cgroups.txt?
> +static char *print_whitelist(struct dev_cgroup *devcgroup, int *len)
> +{
> + char *buf, *s, acc[4];
> + struct dev_whitelist_item *wh;
> + int ret;
> + int count = 0;
> + char maj[10], min[10];
> +
> + buf = kmalloc(4096, GFP_KERNEL);
> + if (!buf)
> + return ERR_PTR(-ENOMEM);
> + s = buf;
> + *s = '\0';
> + *len = 0;
> +
> + spin_lock(&devcgroup->lock);
> + list_for_each_entry(wh, &devcgroup->whitelist, list) {
> + set_access(acc, wh->access);
> + set_majmin(maj, 10, wh->major);
> + set_majmin(min, 10, wh->minor);
> + ret = snprintf(s, 4095-(s-buf), "%c %s:%s %s\n",
> + type_to_char(wh->type), maj, min, acc);
> + if (s+ret >= buf+4095) {
> + kfree(buf);
> + buf = ERR_PTR(-ENOMEM);
> + break;
> + }
> + s += ret;
> + *len += ret;
> + count++;
> + }
> + spin_unlock(&devcgroup->lock);
> +
> + return buf;
> +}
That's rather ugly-looking. We can't use seq_file here?
next prev parent reply other threads:[~2008-03-27 9:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-26 18:05 [PATCH 1/1] cgroups: implement device whitelist (v6) Serge E. Hallyn
2008-03-27 9:04 ` Andrew Morton [this message]
2008-03-27 9:07 ` Li Zefan
2008-03-27 16:24 ` Serge E. Hallyn
2008-03-27 16:40 ` Paul Menage
2008-03-27 17:37 ` Serge E. Hallyn
2008-03-29 8:18 ` Pavel Machek
2008-03-31 14:00 ` Serge E. Hallyn
2008-04-01 12:32 ` Pavel Machek
2008-04-01 12:34 ` Alexey Dobriyan
2008-04-01 22:07 ` Serge E. Hallyn
-- strict thread matches above, loose matches on Subject: below --
2008-03-19 20:56 Serge E. Hallyn
2008-03-19 20:56 ` Serge E. Hallyn
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=20080327020403.5547e43f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=daniel@hozac.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=serue@us.ibm.com \
--cc=xemul@openvz.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.