linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aleksa Sarai <asarai@suse.de>
To: Tejun Heo <tj@kernel.org>
Cc: 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 17:49:36 +1000	[thread overview]
Message-ID: <379e5b13-29d4-ca75-1935-0a64f3db8d27@suse.de> (raw)
In-Reply-To: <20160720231949.GB19588@mtj.duckdns.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 find it quite troubling 
that the usecase of an ordinary user on a system trying to use something 
as useful as cgroups is considered to be "solved" by asking your 
administrator (or systemd) to do it for you. "Delegating explicitly" is 
punting on the problem, by saying "just get the administrator to do the 
setup for you". What if you don't have the opportunity to do that, and 
it takes you 4 weeks of sending emails for you to get the administrator 
to do _anything_?

This is something I'm trying to fix with my recent work with rootless 
containers (and quite a few other people are trying to fix it too). 
Currently we just simply can't do certain operations as an unprivileged 
user that would be possible *if we could just use cgroups*. Things like 
the freezer cgroup would be invaluable for containers, and I guarantee 
that the Chromium and Firefox folks would find it useful to be able to 
limit browser processes in a similar way.

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

  reply	other threads:[~2016-07-21  7:44 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 ` [PATCH v1 2/3] cgroup: allow for unprivileged subtree management Aleksa Sarai
2016-07-20 15:45   ` 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 [this message]
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=379e5b13-29d4-ca75-1935-0a64f3db8d27@suse.de \
    --to=asarai@suse.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --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;
as well as URLs for NNTP newsgroup(s).