Quoting Tejun Heo (t...@kernel.org):
> Hello, Aleksa.
>
> On Fri, Jul 22, 2016 at 06:30:07PM +1000, Aleksa Sarai wrote:
> > Just to be clear, the "ns subdir operation" is a cgroup namespaced process
> > moving A -> A_subdir which is racing against some administrative process
> > moving everything
On Fri, Jul 22, 2016 at 06:24:25PM +1000, Aleksa Sarai wrote:
> > > 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 ha
Hello, Aleksa.
On Fri, Jul 22, 2016 at 06:30:07PM +1000, Aleksa Sarai wrote:
> Just to be clear, the "ns subdir operation" is a cgroup namespaced process
> moving A -> A_subdir which is racing against some administrative process
> moving everything from A -> B (but not wanting to move A -> A_subdi
So if I as the cgroup ns owner am moving a task from A to A_subdir, the
admin scanning tasks in all of A may miss this task in motion because
all the tasks files can't be scanned atomically?
So, the admin just wants to move processes from A and only A to B. It
doesn't wanna interfere with proce
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 tas
Hello,
On Thu, Jul 21, 2016 at 11:16:42AM -0700, James Bottomley wrote:
> OK so a theoretical (not saying it's implementable, we'll have to
> explore that) way of fixing all of this is to have separate views of
> the tree. If the admin always saw everything in A, even if the
> cgroupns had create
On Thu, 2016-07-21 at 11:50 -0400, Tejun Heo wrote:
> Hello, James.
>
> On Thu, Jul 21, 2016 at 08:34:36AM -0700, James Bottomley wrote:
> > So if I as the cgroup ns owner am moving a task from A to A_subdir,
> > the admin scanning tasks in all of A may miss this task in motion
> > because all th
Hello, James.
On Thu, Jul 21, 2016 at 08:34:36AM -0700, James Bottomley wrote:
> So if I as the cgroup ns owner am moving a task from A to A_subdir, the
> admin scanning tasks in all of A may miss this task in motion because
> all the tasks files can't be scanned atomically?
So, the admin just wa
On Thu, 2016-07-21 at 11:26 -0400, Tejun Heo wrote:
> Hello, James.
>
> On Thu, Jul 21, 2016 at 08:16:34AM -0700, James Bottomley wrote:
> > > 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
Hello, James.
On Thu, Jul 21, 2016 at 08:16:34AM -0700, James Bottomley wrote:
> > 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 an
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 autom
Quoting Aleksa Sarai (asa...@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
> rea
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
>
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 ce
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
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 downsid
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 use
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 pol
On Thu, 2016-07-21 at 09:33 -0500, Serge E. Hallyn wrote:
> Quoting Aleksa Sarai (asa...@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 cont
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
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
Quoting Aleksa Sarai (asa...@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 th
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
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 violat
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)
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 m
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
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 f
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
29 matches
Mail list logo
