From: "Serge E. Hallyn" <serge@hallyn.com>
To: Aristeu Rozanski <aris@redhat.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
Tejun Heo <tj@kernel.org>,
Serge Hallyn <serge.hallyn@canonical.com>
Subject: Re: [PATCH v6 9/9] devcg: propagate local changes down the hierarchy
Date: Mon, 11 Feb 2013 17:42:59 +0000 [thread overview]
Message-ID: <20130211174259.GA18179@mail.hallyn.com> (raw)
In-Reply-To: <20130211143241.GF30962@redhat.com>
Quoting Aristeu Rozanski (aris@redhat.com):
> On Sat, Feb 09, 2013 at 04:04:02AM +0000, Serge E. Hallyn wrote:
> > Quoting Aristeu Rozanski (aris@redhat.com):
> > > devcg: propagate local changes down the hierarchy
> > >
> > > This patch makes all changes propagate down in hierarchy respecting when
> > > possible local configurations.
> > >
> > > Behavior changes will clean up exceptions in all the children except when the
> > > parent changes the behavior from allow to deny and the child's behavior was
> > > already deny, in which case the local exceptions will be reused. The inverse
> > > is not possible: you can't have a parent with behavior deny and a child with
> > > behavior accept.
> > >
> > > New exceptions allowing additional access to devices won't be propagated, but
> > > it'll be possible to add an exception to access all of part of the newly
> > > allowed device(s).
> > >
> > > New exceptions disallowing access to devices will be propagated down and the
> > > local group's exceptions will be revalidated for the new situation.
> > > Example:
> > > A
> > > / \
> > > B
> > >
> > > group behavior exceptions
> > > A allow "b 8:* rwm", "c 116:1 rw"
> > > B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
> > >
> > > If a new exception is added to group A:
> > > # echo "c 116:* r" > A/devices.deny
> > > it'll propagate down and after revalidating B's local exceptions, the exception
> > > "c 116:2 rwm" will be removed.
> > >
> > > In case parent behavior or exceptions change and local settings are not
> > > allowed anymore, they'll be deleted.
> >
> > Do you have a use case which would be broken if we simply refuse to
> > allow behavior changes for any cgroup with children?
> >
> > It seems like that would drastically simplify much of this. We would
> > no longer need local.exceptions at all, right? Your comment says
> >
> > * local set rules, saved so when a parent propagates new rules, the
> > * local preferences can be preserved
> >
> > but if there were no parent behavior changes, then any exception change
> > in a parent could be enforced by simply removing violating exceptions
> > in the child, and subsequently refusing the addition of new rules in the
> > child which are not allowed in the parent. Both of which you already do.
> >
> > Or am I thinking wrongly?
>
> That would be an option even simpler than not keeping local settings. In
> production I doubt the sysadmin will keep playing with permissions,
> although until one gets right, it'll be annoying as hell to have to
> remove the whole hierarchy because you forgot to add a certain device to
> the list.
Note I said only forbid behavior changes - not exception changes - to
cgroups with children.
-serge
next prev parent reply other threads:[~2013-02-11 17:42 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-30 17:11 [PATCH v4 0/9] devcg: introduce proper hierarchy support aris
2013-01-30 17:11 ` [PATCH v4 1/9] device_cgroup: prepare exception list handling functions for two lists aris
[not found] ` <20130130171101.263587090-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 19:34 ` Serge E. Hallyn
2013-01-30 19:34 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 2/9] devcg: reorder device exception functions aris
[not found] ` <20130130171101.406627645-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 19:44 ` Serge E. Hallyn
2013-01-30 19:44 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 3/9] device_cgroup: keep track of local group settings aris-H+wXaHxf7aLQT0dZR+AlfA
2013-01-30 17:11 ` aris
[not found] ` <20130130171101.538945424-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 20:01 ` Serge E. Hallyn
2013-01-30 20:01 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 4/9] devcg: expand may_access() logic aris-H+wXaHxf7aLQT0dZR+AlfA
2013-01-30 17:11 ` aris
[not found] ` <20130130171101.690972553-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 20:09 ` Serge E. Hallyn
2013-01-30 20:09 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 5/9] devcg: prepare may_access() for hierarchy support aris
[not found] ` <20130130171101.812377398-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 20:30 ` Serge E. Hallyn
2013-01-30 20:30 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 6/9] devcg: use css_online and css_offline aris
[not found] ` <20130130171101.947461296-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 20:40 ` Serge E. Hallyn
2013-01-30 20:40 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 7/9] devcg: split single exception copy from dev_exceptions_copy() aris-H+wXaHxf7aLQT0dZR+AlfA
2013-01-30 17:11 ` aris
[not found] ` <20130130171102.108794435-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 20:42 ` Serge E. Hallyn
2013-01-30 20:42 ` Serge E. Hallyn
2013-01-30 17:11 ` [PATCH v4 8/9] devcg: refactor dev_exception_clean() aris-H+wXaHxf7aLQT0dZR+AlfA
2013-01-30 17:11 ` aris
2013-01-30 20:47 ` Serge E. Hallyn
[not found] ` <20130130204730.GF8507-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-01-30 20:49 ` Aristeu Rozanski
2013-01-30 20:49 ` Aristeu Rozanski
[not found] ` <20130130204917.GL17632-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-01-30 20:50 ` Tejun Heo
2013-01-30 20:50 ` Tejun Heo
[not found] ` <CAOS58YOHkK9xTBPFAXKksrwP7ZxQc_WuGOp39D94Z1pBsFHfjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-01-31 2:15 ` Li Zefan
2013-01-31 2:15 ` Li Zefan
2013-01-31 15:13 ` Aristeu Rozanski
2013-01-31 15:13 ` Aristeu Rozanski
2013-01-30 17:11 ` [PATCH v4 9/9] devcg: propagate local changes down the hierarchy aris
[not found] ` <20130130171102.390708521-cd6kKtb6gxi3M6m420IelR/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-01-30 21:35 ` Serge E. Hallyn
2013-01-30 21:35 ` Serge E. Hallyn
2013-01-31 4:19 ` Serge E. Hallyn
2013-01-31 4:19 ` Serge E. Hallyn
[not found] ` <20130131041932.GB14576-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-01-31 22:00 ` Aristeu Rozanski
2013-01-31 22:00 ` Aristeu Rozanski
2013-01-31 4:38 ` Serge E. Hallyn
[not found] ` <20130131043839.GA14726-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-01-31 22:03 ` Aristeu Rozanski
2013-01-31 22:03 ` Aristeu Rozanski
2013-02-01 19:09 ` [PATCH v5 " Aristeu Rozanski
2013-02-01 19:09 ` Aristeu Rozanski
[not found] ` <20130201190958.GP17632-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-02 16:13 ` Serge E. Hallyn
2013-02-02 16:13 ` Serge E. Hallyn
[not found] ` <20130202161341.GA11284-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-02-04 15:03 ` Aristeu Rozanski
2013-02-04 15:03 ` Aristeu Rozanski
[not found] ` <20130204150307.GQ17632-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-04 15:17 ` Serge Hallyn
2013-02-04 15:17 ` Serge Hallyn
2013-02-02 16:20 ` Serge E. Hallyn
2013-02-02 16:20 ` Serge E. Hallyn
[not found] ` <20130202162052.GB11284-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-02-04 15:09 ` Aristeu Rozanski
2013-02-04 15:09 ` Aristeu Rozanski
2013-02-05 18:36 ` [PATCH v6 " Aristeu Rozanski
2013-02-05 18:36 ` Aristeu Rozanski
[not found] ` <20130205183646.GT17632-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-09 3:53 ` Serge E. Hallyn
2013-02-09 3:53 ` Serge E. Hallyn
[not found] ` <20130209035357.GA31122-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-02-11 14:30 ` Aristeu Rozanski
2013-02-11 14:30 ` Aristeu Rozanski
2013-02-09 4:04 ` Serge E. Hallyn
2013-02-09 4:04 ` Serge E. Hallyn
[not found] ` <20130209040402.GA31942-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-02-11 14:32 ` Aristeu Rozanski
2013-02-11 14:32 ` Aristeu Rozanski
2013-02-11 17:42 ` Serge E. Hallyn [this message]
[not found] ` <20130211174259.GA18179-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-02-11 18:38 ` Aristeu Rozanski
2013-02-11 18:38 ` Aristeu Rozanski
2013-02-11 18:52 ` Serge E. Hallyn
[not found] ` <20130211185239.GA18779-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2013-02-11 19:02 ` Aristeu Rozanski
2013-02-11 19:02 ` Aristeu Rozanski
[not found] ` <20130211190251.GH30962-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-11 20:47 ` Serge Hallyn
2013-02-11 20:47 ` Serge 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=20130211174259.GA18179@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=aris@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@canonical.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 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.