From: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
To: Aleksa Sarai <asarai-l3A5Bk7waGM@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
"Serge E. Hallyn"
<serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>,
Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Chris Wilson
<chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Christian Brauner <cbrauner-l3A5Bk7waGM@public.gmane.org>,
dev-IGmTWi+3HBZvNhPySn5qfx2eb7JE58TQ@public.gmane.org,
James Bottomley
<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
Date: Thu, 21 Jul 2016 09:33:30 -0500 [thread overview]
Message-ID: <20160721143330.GA5751@mail.hallyn.com> (raw)
In-Reply-To: <379e5b13-29d4-ca75-1935-0a64f3db8d27-l3A5Bk7waGM@public.gmane.org>
Quoting Aleksa Sarai (asarai-l3A5Bk7waGM@public.gmane.org):
> >>I feel like the permission model makes sense in certain cases (the common
> >>ancestor restriction, as well as the ability for a parent to apply limits to
> >>children by setting its own limits). Neither of those are violated (if you
> >>read the commit that introduced the common ancestor restriction).
> >>
> >>Maybe if you give me a usecase of when it might be important that a process
> >>must not be able to move to a sub-cgroup of its current one, I might be able
> >>to understand your concerns? From my perspective, I think that's actually
> >>quite useful.
> >
> >cgroup is used to keep track of which processes belong where and
> >allowing processes to be moved out of its cgroup like this would be
> >surprising to say the least.
>
> Would you find it acceptable if we added a bit that would make this
> not happen (you could specify that a cgroup should not allow a
> process to move itself to a sub-cgroup)? Or an aggregate
> cgroup.procs that gives you all of the processes in the entire
> branch of the tree? Surely this is something that can be fixed
> without unnecessarily restricting users from doing useful things.
>
> >>The reason I'm doing this is so that we might be able to _practically_ use
> >>cgroups as an unprivileged user (something that will almost certainly be
> >>useful to not just the container crowd, but people also planning on using
> >>cgroups as advanced forms of rlimits).
> >
> >I don't get why we need this fragile dance with permissions at all
> >when the same functionality can be achieved by delegating explicitly.
>
> The key words being "unprivileged user". Currently, if I am a
> regular user on a system and I want to use the freezer cgroup to
> pause a process I am running, I have to *go to the administrator and
> ask them to give me permission to do that*. Why is that necessary? I
Ths is of course solvable using something like libpam-cgfs or
libpam-cgm (and others). Since this sounds like a question of
policy, not mechanism, userspace seems like the right place. Is
there a downside to that (or, as Tejun put it, "delegating explicitly")?
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Aleksa Sarai <asarai@suse.de>
Cc: Tejun Heo <tj@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.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>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
Christian Brauner <cbrauner@suse.de>,
dev@opencontainers.org,
James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
Date: Thu, 21 Jul 2016 09:33:30 -0500 [thread overview]
Message-ID: <20160721143330.GA5751@mail.hallyn.com> (raw)
In-Reply-To: <379e5b13-29d4-ca75-1935-0a64f3db8d27@suse.de>
Quoting Aleksa Sarai (asarai@suse.de):
> >>I feel like the permission model makes sense in certain cases (the common
> >>ancestor restriction, as well as the ability for a parent to apply limits to
> >>children by setting its own limits). Neither of those are violated (if you
> >>read the commit that introduced the common ancestor restriction).
> >>
> >>Maybe if you give me a usecase of when it might be important that a process
> >>must not be able to move to a sub-cgroup of its current one, I might be able
> >>to understand your concerns? From my perspective, I think that's actually
> >>quite useful.
> >
> >cgroup is used to keep track of which processes belong where and
> >allowing processes to be moved out of its cgroup like this would be
> >surprising to say the least.
>
> Would you find it acceptable if we added a bit that would make this
> not happen (you could specify that a cgroup should not allow a
> process to move itself to a sub-cgroup)? Or an aggregate
> cgroup.procs that gives you all of the processes in the entire
> branch of the tree? Surely this is something that can be fixed
> without unnecessarily restricting users from doing useful things.
>
> >>The reason I'm doing this is so that we might be able to _practically_ use
> >>cgroups as an unprivileged user (something that will almost certainly be
> >>useful to not just the container crowd, but people also planning on using
> >>cgroups as advanced forms of rlimits).
> >
> >I don't get why we need this fragile dance with permissions at all
> >when the same functionality can be achieved by delegating explicitly.
>
> The key words being "unprivileged user". Currently, if I am a
> regular user on a system and I want to use the freezer cgroup to
> pause a process I am running, I have to *go to the administrator and
> ask them to give me permission to do that*. Why is that necessary? I
Ths is of course solvable using something like libpam-cgfs or
libpam-cgm (and others). Since this sounds like a question of
policy, not mechanism, userspace seems like the right place. Is
there a downside to that (or, as Tejun put it, "delegating explicitly")?
next prev parent reply other threads:[~2016-07-21 14:33 UTC|newest]
Thread overview: 62+ 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
[not found] ` <20160718161816.13040-1-asarai-l3A5Bk7waGM@public.gmane.org>
2016-07-18 16:18 ` [PATCH v1 2/3] cgroup: allow for unprivileged subtree management Aleksa Sarai
2016-07-18 16:18 ` Aleksa Sarai
[not found] ` <20160718161816.13040-3-asarai-l3A5Bk7waGM@public.gmane.org>
2016-07-20 15:45 ` Tejun Heo
2016-07-20 15:45 ` Tejun Heo
[not found] ` <20160720154557.GF4574-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-20 22:59 ` Aleksa Sarai
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-18 16:18 ` Aleksa Sarai
[not found] ` <20160718161816.13040-4-asarai-l3A5Bk7waGM@public.gmane.org>
2016-07-20 15:51 ` Tejun Heo
2016-07-20 15:51 ` Tejun Heo
[not found] ` <20160720155147.GG4574-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-20 22:58 ` Aleksa Sarai
2016-07-20 22:58 ` Aleksa Sarai
[not found] ` <6e975d80-4077-fb8b-ec84-708e37c8e149-l3A5Bk7waGM@public.gmane.org>
2016-07-20 23:02 ` Tejun Heo
2016-07-20 23:02 ` Tejun Heo
[not found] ` <20160720230228.GA19588-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-20 23:18 ` Aleksa Sarai
2016-07-20 23:18 ` Aleksa Sarai
[not found] ` <982fcf3a-3685-9bd7-dd95-7bff255c9421-l3A5Bk7waGM@public.gmane.org>
2016-07-20 23:19 ` Tejun Heo
2016-07-20 23:19 ` Tejun Heo
[not found] ` <20160720231949.GB19588-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-21 7:49 ` Aleksa Sarai
2016-07-21 7:49 ` Aleksa Sarai
[not found] ` <379e5b13-29d4-ca75-1935-0a64f3db8d27-l3A5Bk7waGM@public.gmane.org>
2016-07-21 14:33 ` Serge E. Hallyn [this message]
2016-07-21 14:33 ` Serge E. Hallyn
[not found] ` <20160721143330.GA5751-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-07-21 14:37 ` Aleksa Sarai
2016-07-21 14:37 ` Aleksa Sarai
[not found] ` <2dc90947-cee7-90a9-3e60-4ca7c0de29d3-l3A5Bk7waGM@public.gmane.org>
2016-07-21 15:01 ` Tejun Heo
2016-07-21 15:01 ` Tejun Heo
2016-07-21 15:09 ` Serge E. Hallyn
2016-07-21 15:09 ` Serge E. Hallyn
2016-07-21 14:51 ` James Bottomley
2016-07-21 14:51 ` James Bottomley
[not found] ` <1469112709.2331.11.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-21 14:59 ` Tejun Heo
2016-07-21 14:59 ` Tejun Heo
[not found] ` <20160721145905.GC22680-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-21 15:07 ` Aleksa Sarai
2016-07-21 15:07 ` Aleksa Sarai
2016-07-21 15:04 ` Tejun Heo
2016-07-21 14:52 ` Tejun Heo
2016-07-21 14:52 ` Tejun Heo
[not found] ` <20160721145242.GB22680-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-21 15:04 ` James Bottomley
2016-07-21 15:04 ` James Bottomley
[not found] ` <1469113456.2331.16.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-21 15:07 ` Tejun Heo
2016-07-21 15:07 ` Tejun Heo
[not found] ` <20160721150740.GF22680-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-21 15:16 ` James Bottomley
2016-07-21 15:16 ` James Bottomley
2016-07-21 15:26 ` Tejun Heo
[not found] ` <20160721152648.GA23759-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-21 15:34 ` James Bottomley
2016-07-21 15:34 ` James Bottomley
[not found] ` <1469115276.2331.23.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-21 15:50 ` Tejun Heo
2016-07-21 15:50 ` Tejun Heo
[not found] ` <20160721155046.GB23759-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-07-21 18:16 ` James Bottomley
2016-07-21 18:16 ` James Bottomley
[not found] ` <1469125002.2331.54.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-21 21:06 ` Tejun Heo
2016-07-21 21:06 ` Tejun Heo
2016-07-22 8:30 ` Aleksa Sarai
[not found] ` <177bbc17-5c75-1ff8-0b1f-0c5601fa7e6b-l3A5Bk7waGM@public.gmane.org>
2016-07-25 18:38 ` Tejun Heo
2016-07-25 18:38 ` Tejun Heo
[not found] ` <20160725183801.GE19588-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-07-25 22:54 ` Serge E. Hallyn
2016-07-25 22:54 ` Serge E. Hallyn
2016-07-22 8:24 ` Aleksa Sarai
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=20160721143330.GA5751@mail.hallyn.com \
--to=serge-a9i7lubdfnhqt0dzr+alfa@public.gmane.org \
--cc=James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
--cc=adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=asarai-l3A5Bk7waGM@public.gmane.org \
--cc=cbrauner-l3A5Bk7waGM@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org \
--cc=dev-IGmTWi+3HBZvNhPySn5qfx2eb7JE58TQ@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.