Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1445613 > unrolled thread

[PATCH v1 0/3] cgroup: allow for unprivileged management

Back to article view | Back to linux.kernel

Contents

  [PATCH v1 0/3] cgroup: allow for unprivileged management Aleksa Sarai <asarai@suse.de> - 2016-07-18 18:20 +0200
    [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-18 18:20 +0200
      Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-20 18:00 +0200
        Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-21 01:00 +0200
          Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 01:10 +0200
            Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-21 01:20 +0200
              Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 01:20 +0200
                Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-21 09:50 +0200
                  Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-21 16:40 +0200
                    Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 17:10 +0200
                    Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants "Serge E. Hallyn" <serge@hallyn.com> - 2016-07-21 17:10 +0200
                  Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants "Serge E. Hallyn" <serge@hallyn.com> - 2016-07-21 16:40 +0200
                    Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-07-21 17:00 +0200
                      Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 17:00 +0200
                        Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-21 17:10 +0200
                          Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 17:10 +0200
                  Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 17:00 +0200
                    Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-07-21 17:10 +0200
                      Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 17:10 +0200
                        Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-07-21 17:20 +0200
                          Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 17:30 +0200
                            Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-07-21 17:40 +0200
                              Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 18:00 +0200
                                Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-07-21 20:20 +0200
                                  Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-21 23:10 +0200
                                Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-22 10:30 +0200
                                  Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-25 20:40 +0200
                        Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Aleksa Sarai <asarai@suse.de> - 2016-07-22 10:20 +0200
                          Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for  direct descendants Tejun Heo <tj@kernel.org> - 2016-07-25 20:50 +0200

Page 1 of 2  [1] 2  Next page →

#1445613 — [PATCH v1 0/3] cgroup: allow for unprivileged management

This is a rewrite of my old cgroup unprivileged subtree management[1]
patchset. Rather than magically creating a new cgroup, I've instead
modified kernfs so that we can have custom permission hooks. The
following only applies to cgroupv2 trees, due to the fact that cgroupv1
doesn't explicitly require that cgroups be hierarchical.

You can only create a new subtree if you either would traditionally have
write access, or you are attempting to create a new cgroup under the
root cgroup of your current cgroup namespace (and you have CAP_SYS_ADMIN
in the user namespace pinned by the cgroup namespace). This means that
users would only be able to create sub-cgroups of their current cgroup
using this method.

In addition, I relaxed one of the ancestor restrictions so that you can
move to direct descendants of the current cgroup without needing to be
able to join the current cgroup you're in (because that restriction
doesn't make much sense).

[1]: http://marc.info/?l=linux-kernel&m=146319604331859

Cc: dev@opencontainers.org

Aleksa Sarai (3):
  kernfs: add support for custom per-sb permission hooks
  cgroup: allow for unprivileged subtree management
  cgroup: relax common ancestor restriction for direct descendants

 fs/kernfs/inode.c      | 13 +++++++-
 include/linux/kernfs.h |  3 ++
 kernel/cgroup.c        | 86 +++++++++++++++++++++++++++++++++++++++++++++-----
 3 files changed, 93 insertions(+), 9 deletions(-)

-- 
2.9.0

[toc] | [next] | [standalone]

#1445620 — [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

If we're moving from a parent to a direct descendant, the only end
result (on cgroupv2 hierarchies) is that the process experiences more
restrictive resource limits. Thus, there's no reason to restrict
processes from moving to direct descendants based on whether or not they
have cgroup.procs write access to their current cgroup.

This is important for unprivileged subtree management, as it allows
unprivileged processes to move to their newly create subtrees.

Cc: dev@opencontainers.org
Signed-off-by: Aleksa Sarai <asarai@suse.de>
---
 kernel/cgroup.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 4559baa7eabd..fa403357ba91 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2859,14 +2859,22 @@ static int cgroup_procs_write_permission(struct task_struct *task,
 		cgrp = task_cgroup_from_root(task, &cgrp_dfl_root);
 		spin_unlock_irq(&css_set_lock);
 
-		while (!cgroup_is_descendant(dst_cgrp, cgrp))
-			cgrp = cgroup_parent(cgrp);
-
-		ret = -ENOMEM;
-		inode = kernfs_get_inode(sb, cgrp->procs_file.kn);
-		if (inode) {
-			ret = inode_permission(inode, MAY_WRITE);
-			iput(inode);
+		/*
+		 * If we are moving to a descendant of our current cgroup, we
+		 * can only further restrict the cgroup limits we must follow.
+		 * Thus, it doesn't make sense to restrict the cgroup.procs
+		 * write.
+		 */
+		if (!cgroup_is_descendant(dst_cgrp, cgrp)) {
+			while (!cgroup_is_descendant(dst_cgrp, cgrp))
+				cgrp = cgroup_parent(cgrp);
+
+			ret = -ENOMEM;
+			inode = kernfs_get_inode(sb, cgrp->procs_file.kn);
+			if (inode) {
+				ret = inode_permission(inode, MAY_WRITE);
+				iput(inode);
+			}
 		}
 	}
 
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1447318 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa.

On Tue, Jul 19, 2016 at 02:18:16AM +1000, Aleksa Sarai wrote:
> If we're moving from a parent to a direct descendant, the only end
> result (on cgroupv2 hierarchies) is that the process experiences more
> restrictive resource limits. Thus, there's no reason to restrict
> processes from moving to direct descendants based on whether or not they
> have cgroup.procs write access to their current cgroup.
> 
> This is important for unprivileged subtree management, as it allows
> unprivileged processes to move to their newly create subtrees.

I don't think we can do this as this allows a sub-cgroup to steal an
ancestor's process whether the ancestor likes it or not.  A process
being put in a context where it's more restricted without whatever is
managing that part of cgroup hierarchy is not ok, at all.  Please also
note that nobody expects its processes to be stolen underneath it.
This would be a management nightmare.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447525 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

>> If we're moving from a parent to a direct descendant, the only end
>> result (on cgroupv2 hierarchies) is that the process experiences more
>> restrictive resource limits. Thus, there's no reason to restrict
>> processes from moving to direct descendants based on whether or not they
>> have cgroup.procs write access to their current cgroup.
>>
>> This is important for unprivileged subtree management, as it allows
>> unprivileged processes to move to their newly create subtrees.
>
> I don't think we can do this as this allows a sub-cgroup to steal an
> ancestor's process whether the ancestor likes it or not.  A process
> being put in a context where it's more restricted without whatever is
> managing that part of cgroup hierarchy is not ok, at all.  Please also
> note that nobody expects its processes to be stolen underneath it.
> This would be a management nightmare.

I'm not sure what you mean by "steal". The user doing the migration owns 
the process, so I would argue that they aren't "stealing" anything. 
While a higher level process might not know where precisely in the 
hierarchy the process is, they'll know it that it must be a sub-cgroup 
of the one they were put in (meaning the parent can still impose 
restrictions without any issue).

If you want, we can make it so that an unprivileged user migrating 
processes to a child cgroup only works if you're in the same cgroup 
namespace (and have CAP_SYS_ADMIN in the pinned user namespace, etc). 
The current setup would obviously still work, but you'd add a permission 
for users that just want to be able to limit their own processes. IIRC 
we need to update cgroup_procs_write_permission() anyway. By having the 
cgroup namespace requirement, you'd definitely have to "own" the process 
in every sense of the word I can imagine.

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

[toc] | [prev] | [next] | [standalone]

#1447527 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa.

On Thu, Jul 21, 2016 at 08:58:32AM +1000, Aleksa Sarai wrote:
> I'm not sure what you mean by "steal". The user doing the migration owns the

In the sense that the ancestor cgroup can be modified by one of its
descendants even when that descendant doesn't have enough permission
to modify the ancestor.

> process, so I would argue that they aren't "stealing" anything. While a
> higher level process might not know where precisely in the hierarchy the
> process is, they'll know it that it must be a sub-cgroup of the one they
> were put in (meaning the parent can still impose restrictions without any
> issue).

Hmmm... it's not just about the ownership of the process itself.  If
it had been, we wouldn't have bothered with permission model on cgroup
hierarchy itself.  It's also about who is allowed to modify a given
cgroup and what you're proposing violates that.

> If you want, we can make it so that an unprivileged user migrating processes
> to a child cgroup only works if you're in the same cgroup namespace (and
> have CAP_SYS_ADMIN in the pinned user namespace, etc). The current setup
> would obviously still work, but you'd add a permission for users that just
> want to be able to limit their own processes. IIRC we need to update
> cgroup_procs_write_permission() anyway. By having the cgroup namespace
> requirement, you'd definitely have to "own" the process in every sense of
> the word I can imagine.

Maybe I'm misunderstanding but I can't see how that would change the
situation in a significant way.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447530 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

>> process, so I would argue that they aren't "stealing" anything. While a
>> higher level process might not know where precisely in the hierarchy the
>> process is, they'll know it that it must be a sub-cgroup of the one they
>> were put in (meaning the parent can still impose restrictions without any
>> issue).
>
> Hmmm... it's not just about the ownership of the process itself.  If
> it had been, we wouldn't have bothered with permission model on cgroup
> hierarchy itself.  It's also about who is allowed to modify a given
> cgroup and what you're proposing violates that.

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.

>> If you want, we can make it so that an unprivileged user migrating processes
>> to a child cgroup only works if you're in the same cgroup namespace (and
>> have CAP_SYS_ADMIN in the pinned user namespace, etc). The current setup
>> would obviously still work, but you'd add a permission for users that just
>> want to be able to limit their own processes. IIRC we need to update
>> cgroup_procs_write_permission() anyway. By having the cgroup namespace
>> requirement, you'd definitely have to "own" the process in every sense of
>> the word I can imagine.
>
> Maybe I'm misunderstanding but I can't see how that would change the
> situation in a significant way.

Well, it would avoid the issue of a process being moved against *its* 
will. The process would have to be complicit in joining (or unsharing) a 
cgroup namespace. I'm not sure I really agree with the argument that a 
higher level process should be able to stop a process from imposing more 
*stringent* limits on itself if the process is complicit in setting 
those limits (see above).

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).

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

[toc] | [prev] | [next] | [standalone]

#1447531 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa.

On Thu, Jul 21, 2016 at 09:18:59AM +1000, Aleksa Sarai wrote:
> 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.

> > Maybe I'm misunderstanding but I can't see how that would change the
> > situation in a significant way.
> 
> Well, it would avoid the issue of a process being moved against *its* will.
> The process would have to be complicit in joining (or unsharing) a cgroup
> namespace. I'm not sure I really agree with the argument that a higher level
> process should be able to stop a process from imposing more *stringent*
> limits on itself if the process is complicit in setting those limits (see
> above).
> 
> 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.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447682 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

>> 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/

[toc] | [prev] | [next] | [standalone]

#1447919 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

>>>> 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")?

Having a PAM module requires getting an administrator to install the PAM 
module (and also presumably audit it, not to mention convincing them 
that your requirement to use containers are significant enough for them 
to do any work). It's the same problem IMO. I understand that LXC allows 
you to do this, but it requires that you get an administrator to 
*install* and support LXC (as well as the shadow-utils setuid binaries 
too). There are cases where you don't have the freedom to do that, and 
also "just get someone to give you privileges temporarily" is again 
punting on the problem.

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

[toc] | [prev] | [next] | [standalone]

#1447953 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa.

On Fri, Jul 22, 2016 at 12:37:42AM +1000, Aleksa Sarai wrote:
> > 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")?
> 
> Having a PAM module requires getting an administrator to install the PAM
> module (and also presumably audit it, not to mention convincing them that
> your requirement to use containers are significant enough for them to do any
> work). It's the same problem IMO. I understand that LXC allows you to do
> this, but it requires that you get an administrator to *install* and support
> LXC (as well as the shadow-utils setuid binaries too). There are cases where
> you don't have the freedom to do that, and also "just get someone to give
> you privileges temporarily" is again punting on the problem.

The administrator has to install a new kernel to get this feature from
kernel side too.  I don't think "to bypass admin" is a strong argument
for a new kernel feature especially when it's likely to cause subtle
issues as in this case.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447955 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

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")?
> 
> Having a PAM module requires getting an administrator to install the
> PAM module (and also presumably audit it, not to mention convincing
> them that your requirement to use containers are significant enough

Right, but that's also the upside.  Just like user namespaces, it *is*
possible that there remain exploitable situations when cgroups are
delegated, and it is up to the admin, not the user, to gauge how
averse they are to that risk.

(Fwiw obviously I am very sympathetic to your goals :)

> for them to do any work). It's the same problem IMO. I understand
> that LXC allows you to do this, but it requires that you get an
> administrator to *install* and support LXC (as well as the
> shadow-utils setuid binaries too). There are cases where you don't
> have the freedom to do that, and also "just get someone to give you
> privileges temporarily" is again punting on the problem.
> 
> -- 
> Aleksa Sarai
> Software Engineer (Containers)
> SUSE Linux GmbH
> https://www.cyphar.com/

[toc] | [prev] | [next] | [standalone]

#1447921 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

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")?

[toc] | [prev] | [next] | [standalone]

#1447939 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

On Thu, 2016-07-21 at 09:33 -0500, Serge E. Hallyn wrote:
> Quoting Aleksa Sarai (asarai@suse.de):

> > > > 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?
> 
> 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")?

Unprivileged containers should "just work" by default as much as
possible.  There are cases where they can't and policy input is
required, like the userns mapping to additional ids beyond the current
one, we can still set up the default case without intervention (a
single mapping root to current id).

What I haven't really heard yet in the debate is the policy reason why
an unprivileged user shouldn't set up their own cgroups as children of
the current ones (inheriting the constraints).

I have heard

 * it would give power to move other tasks to more rigid constraints. 
    To which the answer is only to allow movememnt of tasks in the
   current cgroupns
 * It violates the permissions delegation model.  This one doesn't
   really make too much sense to me: in the same way the userns is root
   in its own domain, cgroups ns is effective root for the restricted
   cgroups (and only for processes within its ns).

Perhaps the question should be asked the other way around:  if we were
explicitly delegating permission to every user in the system to set up
their own sub cgroups, how would you advise it be done?

James

[toc] | [prev] | [next] | [standalone]

#1447947 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, James.

On Thu, Jul 21, 2016 at 07:51:49AM -0700, James Bottomley wrote:
> What I haven't really heard yet in the debate is the policy reason why
> an unprivileged user shouldn't set up their own cgroups as children of
> the current ones (inheriting the constraints).

It's not even about policies.  The interface just can't support
operations like this in a robust way.  We can try to hack enough holes
at it to make some scenarios work but it's all but guaranteed that
such approach is gonna cause painful long-term issues.

> I have heard
> 
>  * it would give power to move other tasks to more rigid constraints. 
>     To which the answer is only to allow movememnt of tasks in the
>    current cgroupns
>  * It violates the permissions delegation model.  This one doesn't
>    really make too much sense to me: in the same way the userns is root
>    in its own domain, cgroups ns is effective root for the restricted
>    cgroups (and only for processes within its ns).
> 
> Perhaps the question should be asked the other way around:  if we were
> explicitly delegating permission to every user in the system to set up
> their own sub cgroups, how would you advise it be done?

Coordinate in userspace.  Request whatever is managing the cgroup
hierarchy to set up delegation.  It's not like permission model is
fully contained in kernel on modern systems anyway.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447949 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

>> I have heard
>>
>>  * it would give power to move other tasks to more rigid constraints.
>>     To which the answer is only to allow movememnt of tasks in the
>>    current cgroupns
>>  * It violates the permissions delegation model.  This one doesn't
>>    really make too much sense to me: in the same way the userns is root
>>    in its own domain, cgroups ns is effective root for the restricted
>>    cgroups (and only for processes within its ns).
>>
>> Perhaps the question should be asked the other way around:  if we were
>> explicitly delegating permission to every user in the system to set up
>> their own sub cgroups, how would you advise it be done?
>
> Coordinate in userspace.  Request whatever is managing the cgroup
> hierarchy to set up delegation.  It's not like permission model is
> fully contained in kernel on modern systems anyway.

My experience with certain systemdaemons' cgroup handling doesn't 
inspire confidence :/ (from the runC side, we've had nothing but 
issues). Also, how do you even boot into a cgroupv2 system with systemd 
(I started backporting patches to openSUSE, but it's still not booting)?

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

[toc] | [prev] | [next] | [standalone]

#1447957 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa.

On Fri, Jul 22, 2016 at 01:07:13AM +1000, Aleksa Sarai wrote:
> > Coordinate in userspace.  Request whatever is managing the cgroup
> > hierarchy to set up delegation.  It's not like permission model is
> > fully contained in kernel on modern systems anyway.
> 
> My experience with certain systemdaemons' cgroup handling doesn't inspire
> confidence :/ (from the runC side, we've had nothing but issues). Also, how

Fix it then.  Working around bugs in userland isn't a justifiable
rationale for adding new kernel features.

> do you even boot into a cgroupv2 system with systemd (I started backporting
> patches to openSUSE, but it's still not booting)?

With devel branch, just passing in the unified hierarchy boot param
seems to work fine here.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447944 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa.

On Thu, Jul 21, 2016 at 05:49:36PM +1000, Aleksa Sarai wrote:
> > > 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.

I understand what you're trying to achieve but don't think cgroup's
filesystem interface can accomodate that.  To support that level of
automatic delegation, the API should be providing enough isolation so
that operations in one domain (user-specific operations) are
transparent from the other (system-wide administration), which simply
isn't true for cgroupfs.  As a simple example, imagine a process being
moved to another cgroup racing against the special operations you're
describing ahead.  Both sides are multi-step operations and there are
no ways of synchronizing against each other from kernel side and the
outcomes can easily be non-sensical.

It is unfortunate but we started with and are bound to carry the
current vfs based interface which was never designed to support the
use cases you're describing in a seamless way and that's why cgroup
supports explicit delegation so that userland can take over the
necessary coordination and implement more complex operations atop.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447952 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

On Thu, 2016-07-21 at 10:52 -0400, Tejun Heo wrote:
> Hello, Aleksa.
> 
> On Thu, Jul 21, 2016 at 05:49:36PM +1000, Aleksa Sarai wrote:
> > > > 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.
> 
> I understand what you're trying to achieve but don't think cgroup's
> filesystem interface can accomodate that.  To support that level of
> automatic delegation, the API should be providing enough isolation so
> that operations in one domain (user-specific operations) are
> transparent from the other (system-wide administration), which simply
> isn't true for cgroupfs.  As a simple example, imagine a process 
> being moved to another cgroup racing against the special operations 
> you're describing ahead.  Both sides are multi-step operations and 
> there are no ways of synchronizing against each other from kernel 
> side and the outcomes can easily be non-sensical.

So if I understand, it's not about actually moving the tasks: echoing
the pid to the tasks file is atomic and we can mediate races there. 
 It's about the debris left behind if the admin (or someone with
delegated authority) moves the task to a wholly different cgroup.

Now we have a cgroup directory in the old cgroup, which the current
task has been removed from, for which the current user has permissions
and could then move the task back to.  Is that the essence of the
problem?

James

[toc] | [prev] | [next] | [standalone]

#1447954 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, James.

On Thu, Jul 21, 2016 at 08:04:16AM -0700, James Bottomley wrote:
> > I understand what you're trying to achieve but don't think cgroup's
> > filesystem interface can accomodate that.  To support that level of
> > automatic delegation, the API should be providing enough isolation so
> > that operations in one domain (user-specific operations) are
> > transparent from the other (system-wide administration), which simply
> > isn't true for cgroupfs.  As a simple example, imagine a process 
> > being moved to another cgroup racing against the special operations 
> > you're describing ahead.  Both sides are multi-step operations and 
> > there are no ways of synchronizing against each other from kernel 
> > side and the outcomes can easily be non-sensical.
> 
> So if I understand, it's not about actually moving the tasks: echoing
> the pid to the tasks file is atomic and we can mediate races there. 

Yeah, each operation is atomic but most meaningul operations are
multi-step.

>  It's about the debris left behind if the admin (or someone with
> delegated authority) moves the task to a wholly different cgroup.
> 
> Now we have a cgroup directory in the old cgroup, which the current
> task has been removed from, for which the current user has permissions
> and could then move the task back to.  Is that the essence of the
> problem?

That'd be one side.  The other side is the one moving.  Let's say the
system admin thing wants to move all processe from A proper to B.  It
would do that by draining processes from A's procs file into B's and
even that is multistep and can race.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1447962 — Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

On Thu, 2016-07-21 at 11:07 -0400, Tejun Heo wrote:
> Hello, James.
> 
> On Thu, Jul 21, 2016 at 08:04:16AM -0700, James Bottomley wrote:
> > > I understand what you're trying to achieve but don't think 
> > > cgroup's filesystem interface can accomodate that.  To support 
> > > that level of automatic delegation, the API should be providing 
> > > enough isolation so that operations in one domain (user-specific 
> > > operations) are transparent from the other (system-wide 
> > > administration), which simply isn't true for cgroupfs.  As a 
> > > simple example, imagine a process being moved to another cgroup 
> > > racing against the special operations you're describing ahead. 
> > >  Both sides are multi-step operations and there are no ways of 
> > > synchronizing against each other from kernel side and the
> > > outcomes can easily be non-sensical.
> > 
> > So if I understand, it's not about actually moving the tasks: 
> > echoing the pid to the tasks file is atomic and we can mediate
> > races there.
 
> 
> Yeah, each operation is atomic but most meaningul operations are
> multi-step.
> 
> >  It's about the debris left behind if the admin (or someone with
> > delegated authority) moves the task to a wholly different cgroup.
> > 
> > Now we have a cgroup directory in the old cgroup, which the current
> > task has been removed from, for which the current user has 
> > permissions and could then move the task back to.  Is that the 
> > essence of the problem?
> 
> That'd be one side.  The other side is the one moving.  Let's say the
> system admin thing wants to move all processe from A proper to B.  It
> would do that by draining processes from A's procs file into B's and
> even that is multistep and can race.

So the second part is that once we allow the creation of
subdirectories, there's no unified tasks file, so there's no way of
draining A proper without enumerating and descending into the cgroupns
created subtrees in A?

James

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web