cgroups(7): documenting cgroups v2 delegation

cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun and Serge

The delegation feature of cgroups v2 has of course been around
for a while now, but was not documented so far in cgroups(7).
I have written some text to describe the delegation feature.
I would be happy to receive suggestions for fixes, improvements,
or corrections to errors, from you (or others). The plain-text
version for (easy review) is shown below. (Please note the FIXME!)

The branch containing the pending cgroups(7) changes can be found at: 
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_cgroup_updates

[[
   Cgroups v2 delegation
       In the context of cgroups, delegation means passing  management
       of  some  subtree  of  the  cgroup hierarchy to a nonprivileged
       process.  Cgroups v1 provides support for delegation  that  was
       accidental  and  not fully secure.  Cgroups v2 supports delega‐
       tion by explicit design.

       Some terminology is required in order to  describe  delegation.
       A delegater is a privileged user (i.e., root) who owns a parent
       cgroup.  A delegatee  is  a  nonprivileged  user  who  will  be
       granted  the  permissions  needed  to  manage some subhierarchy
       under that parent cgroup, known as the delegated subtree.

       To perform delegation, the delegater makes certain  directories
       and  files writable by the delegatee, typically by changing the
       ownership of the objects to be the user ID  of  the  delegatee.
       Assuming that we want to delegate the hierarchy rooted at (say)
       /dlgt_grp and that there are not yet any  child  cgroups  under
       that  cgroup,  the ownership of the following is changed to the
       user ID of the delegatee:

       /dlgt_grp
              Changing the ownership of the root of the subtree  means
              that  any new cgroups created under the subtree (and the
              files they contain) will also be owned by the delegatee.

       /dlgt_grp/cgroup.procs
              Changing the ownership of this file means that the dele‐
              gatee  can move processes into the root of the delegated
              subtree.

       /dlgt_grp/cgroup.subtree_control
              Making this file owned by  the  delegatee  is  optional.
              Doing  so  means that that the delegatee can enable con‐
              trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
              trollers)  in order to further redistribute resources at
              lower levels in  the  subtree.   As  an  alternative  to
              changing the ownership of this file, the delegater might
              instead add selected controllers to this file.

       The delegater should not change the ownership  of  any  of  the
       controller  interfaces  files  (e.g., pids.max, memory.high) in
       dlgt_grp.  Those files are used from the next level  above  the
       delegated  subtree  in  order  to distribute resources into the
       subtree, and the delegatee should not have permission to change
       the resources that are distributed into the delegated subtree.

       After the aforementioned steps have been performed, the delega‐
       tee can create child cgroups within the delegated  subtree  and
       move  processes  between  cgroups in the subtree.  If some con‐
       trollers are present in dlgt_grp/cgroup.subtree_control, or the
       ownership of that file was passed to the delegatee, the delega‐
       tee can also control the further redistribution of  the  corre‐
       sponding resources into the delegated subtree.

       Some delegation containment rules ensure that the delegatee can
       move processes between cgroups within  the  delegated  subtree,
       but  can't  move  processes  from outside the delegated subtree
       into the subtree or vice versa.  A nonprivileged process (i.e.,
       the  delegatee)  can write the PID of a "target" process into a
       cgroup.procs file only if all of the following are true:

       *  The effective  UID  of  the  writer  (i.e.,  the  delegatee)
          matches  the  real  user  ID or the saved set-user-ID of the
          target process.

       *  The writer has write permission on the cgroup.procs file  in
          the destination cgroup.

       *  The  writer has write permission on the cgroup.procs file in
          the common ancestor of the source and  destination  cgroups.
          (In  some  cases,  the  common ancestor may be the source or
          destination cgroup itself.)

          ┌─────────────────────────────────────────────────────┐
          │FIXME                                                │
          ├─────────────────────────────────────────────────────┤
          │Please confirm that the following is correct:        │
          └─────────────────────────────────────────────────────┘

       Note: one consequence of these delegation containment rules  is
       that  the  unprivileged delegatee can't place the first process
       into the delegated subtree; instead, the delegater  must  place
       the  first  process (a process owned by the delegatee) into the
       delegated subtree.
]]

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello, Michael.

On Tue, Jan 02, 2018 at 07:22:05PM +0100, Michael Kerrisk (man-pages) wrote:
>        To perform delegation, the delegater makes certain  directories
>        and  files writable by the delegatee, typically by changing the
>        ownership of the objects to be the user ID  of  the  delegatee.
>        Assuming that we want to delegate the hierarchy rooted at (say)
>        /dlgt_grp and that there are not yet any  child  cgroups  under
>        that  cgroup,  the ownership of the following is changed to the
>        user ID of the delegatee:
> 
>        /dlgt_grp
>               Changing the ownership of the root of the subtree  means
>               that  any new cgroups created under the subtree (and the
>               files they contain) will also be owned by the delegatee.
> 
>        /dlgt_grp/cgroup.procs
>               Changing the ownership of this file means that the dele‐
>               gatee  can move processes into the root of the delegated
>               subtree.
> 
>        /dlgt_grp/cgroup.subtree_control
>               Making this file owned by  the  delegatee  is  optional.
>               Doing  so  means that that the delegatee can enable con‐
>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
>               trollers)  in order to further redistribute resources at
>               lower levels in  the  subtree.   As  an  alternative  to
>               changing the ownership of this file, the delegater might
>               instead add selected controllers to this file.

I'm not sure how useful it is to describe this to be optional.  In the
same sense, cgroup.procs would be optional too as the delegatee can
take control from its first children.  Users of course can choose to
do mix and match as they see fit but outside of the defined model,
there can be surprises - e.g. nsdelegate or some future delegation
aware feature can behave differently.  I think it'd be better to keep
it simple - either a subtree is delegated or not.

>        The delegater should not change the ownership  of  any  of  the
>        controller  interfaces  files  (e.g., pids.max, memory.high) in
>        dlgt_grp.  Those files are used from the next level  above  the
>        delegated  subtree  in  order  to distribute resources into the
>        subtree, and the delegatee should not have permission to change
>        the resources that are distributed into the delegated subtree.

Roman recently added /sys/kernel/cgroup/delegate and
/sys/kernel/cgroup/features.  The former contains newline separated
list of cgroup files which should be chowned on delegation (in
addition to the directory itself) and the latter contains optional
features (currently only nsdelegate).  Roman, can you please update
cgroup-v2.txt accordingly?

The file list was added because the cgroup OOM support added a knob
which belongs to the cgroup itself rather than the parent and we might
have more of those files in the future (not too likely and there won't
be many).

It could be also worthwhile to describe nsdelegate, which prevents
cgroup-namespaced delegatee, which may have the same UID as the
delegator, from writing to interface files in its cgroup root which
belong to the parent.

>        Some delegation containment rules ensure that the delegatee can
>        move processes between cgroups within  the  delegated  subtree,
>        but  can't  move  processes  from outside the delegated subtree
>        into the subtree or vice versa.  A nonprivileged process (i.e.,
>        the  delegatee)  can write the PID of a "target" process into a
>        cgroup.procs file only if all of the following are true:
> 
>        *  The effective  UID  of  the  writer  (i.e.,  the  delegatee)
>           matches  the  real  user  ID or the saved set-user-ID of the
>           target process.

cgroup2 doesn't check the above anymore.

>        *  The writer has write permission on the cgroup.procs file  in
>           the destination cgroup.
> 
>        *  The  writer has write permission on the cgroup.procs file in
>           the common ancestor of the source and  destination  cgroups.
>           (In  some  cases,  the  common ancestor may be the source or
>           destination cgroup itself.)

Also, if nsdelegate is enabled, both the source and destination
cgroups must be visible (cgroup namespace-wise) to the writer.

>           ┌─────────────────────────────────────────────────────┐
>           │FIXME                                                │
>           ├─────────────────────────────────────────────────────┤
>           │Please confirm that the following is correct:        │
>           └─────────────────────────────────────────────────────┘
> 
>        Note: one consequence of these delegation containment rules  is
>        that  the  unprivileged delegatee can't place the first process
>        into the delegated subtree; instead, the delegater  must  place
>        the  first  process (a process owned by the delegatee) into the
>        delegated subtree.

Yeah, that'd be the case.  Seeding of a delegated subtree should be
done by the delegator or before the priviledges are dropped.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello, Michael.

On Tue, Jan 02, 2018 at 07:22:05PM +0100, Michael Kerrisk (man-pages) wrote:
>        To perform delegation, the delegater makes certain  directories
>        and  files writable by the delegatee, typically by changing the
>        ownership of the objects to be the user ID  of  the  delegatee.
>        Assuming that we want to delegate the hierarchy rooted at (say)
>        /dlgt_grp and that there are not yet any  child  cgroups  under
>        that  cgroup,  the ownership of the following is changed to the
>        user ID of the delegatee:
> 
>        /dlgt_grp
>               Changing the ownership of the root of the subtree  means
>               that  any new cgroups created under the subtree (and the
>               files they contain) will also be owned by the delegatee.
> 
>        /dlgt_grp/cgroup.procs
>               Changing the ownership of this file means that the dele‐
>               gatee  can move processes into the root of the delegated
>               subtree.
> 
>        /dlgt_grp/cgroup.subtree_control
>               Making this file owned by  the  delegatee  is  optional.
>               Doing  so  means that that the delegatee can enable con‐
>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
>               trollers)  in order to further redistribute resources at
>               lower levels in  the  subtree.   As  an  alternative  to
>               changing the ownership of this file, the delegater might
>               instead add selected controllers to this file.

I'm not sure how useful it is to describe this to be optional.  In the
same sense, cgroup.procs would be optional too as the delegatee can
take control from its first children.  Users of course can choose to
do mix and match as they see fit but outside of the defined model,
there can be surprises - e.g. nsdelegate or some future delegation
aware feature can behave differently.  I think it'd be better to keep
it simple - either a subtree is delegated or not.

>        The delegater should not change the ownership  of  any  of  the
>        controller  interfaces  files  (e.g., pids.max, memory.high) in
>        dlgt_grp.  Those files are used from the next level  above  the
>        delegated  subtree  in  order  to distribute resources into the
>        subtree, and the delegatee should not have permission to change
>        the resources that are distributed into the delegated subtree.

Roman recently added /sys/kernel/cgroup/delegate and
/sys/kernel/cgroup/features.  The former contains newline separated
list of cgroup files which should be chowned on delegation (in
addition to the directory itself) and the latter contains optional
features (currently only nsdelegate).  Roman, can you please update
cgroup-v2.txt accordingly?

The file list was added because the cgroup OOM support added a knob
which belongs to the cgroup itself rather than the parent and we might
have more of those files in the future (not too likely and there won't
be many).

It could be also worthwhile to describe nsdelegate, which prevents
cgroup-namespaced delegatee, which may have the same UID as the
delegator, from writing to interface files in its cgroup root which
belong to the parent.

>        Some delegation containment rules ensure that the delegatee can
>        move processes between cgroups within  the  delegated  subtree,
>        but  can't  move  processes  from outside the delegated subtree
>        into the subtree or vice versa.  A nonprivileged process (i.e.,
>        the  delegatee)  can write the PID of a "target" process into a
>        cgroup.procs file only if all of the following are true:
> 
>        *  The effective  UID  of  the  writer  (i.e.,  the  delegatee)
>           matches  the  real  user  ID or the saved set-user-ID of the
>           target process.

cgroup2 doesn't check the above anymore.

>        *  The writer has write permission on the cgroup.procs file  in
>           the destination cgroup.
> 
>        *  The  writer has write permission on the cgroup.procs file in
>           the common ancestor of the source and  destination  cgroups.
>           (In  some  cases,  the  common ancestor may be the source or
>           destination cgroup itself.)

Also, if nsdelegate is enabled, both the source and destination
cgroups must be visible (cgroup namespace-wise) to the writer.

>           ┌─────────────────────────────────────────────────────┐
>           │FIXME                                                │
>           ├─────────────────────────────────────────────────────┤
>           │Please confirm that the following is correct:        │
>           └─────────────────────────────────────────────────────┘
> 
>        Note: one consequence of these delegation containment rules  is
>        that  the  unprivileged delegatee can't place the first process
>        into the delegated subtree; instead, the delegater  must  place
>        the  first  process (a process owned by the delegatee) into the
>        delegated subtree.

Yeah, that'd be the case.  Seeding of a delegated subtree should be
done by the delegator or before the priviledges are dropped.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/08/2018 03:14 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Tue, Jan 02, 2018 at 07:22:05PM +0100, Michael Kerrisk (man-pages) wrote:
>>        To perform delegation, the delegater makes certain  directories
>>        and  files writable by the delegatee, typically by changing the
>>        ownership of the objects to be the user ID  of  the  delegatee.
>>        Assuming that we want to delegate the hierarchy rooted at (say)
>>        /dlgt_grp and that there are not yet any  child  cgroups  under
>>        that  cgroup,  the ownership of the following is changed to the
>>        user ID of the delegatee:
>>
>>        /dlgt_grp
>>               Changing the ownership of the root of the subtree  means
>>               that  any new cgroups created under the subtree (and the
>>               files they contain) will also be owned by the delegatee.
>>
>>        /dlgt_grp/cgroup.procs
>>               Changing the ownership of this file means that the dele‐
>>               gatee  can move processes into the root of the delegated
>>               subtree.
>>
>>        /dlgt_grp/cgroup.subtree_control
>>               Making this file owned by  the  delegatee  is  optional.
>>               Doing  so  means that that the delegatee can enable con‐
>>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
>>               trollers)  in order to further redistribute resources at
>>               lower levels in  the  subtree.   As  an  alternative  to
>>               changing the ownership of this file, the delegater might
>>               instead add selected controllers to this file.
> 
> I'm not sure how useful it is to describe this to be optional.  In the
> same sense, cgroup.procs would be optional too as the delegatee can
> take control from its first children.  Users of course can choose to
> do mix and match as they see fit but outside of the defined model,
> there can be surprises - e.g. nsdelegate or some future delegation
> aware feature can behave differently.  I think it'd be better to keep
> it simple - either a subtree is delegated or not.

So, I changed that piece to:

       /dlgt_grp/cgroup.subtree_control
              Changing the ownership of this file  means  that  that  the
              delegatee  can  enable  controllers  (that  are  present in
              /dlgt_grp/cgroup.controllers) in order  to  further  redis‐
              tribute  resources  at lower levels in the subtree.  (As an
              alternative to changing the ownership  of  this  file,  the
              delegater  might  instead  add selected controllers to this
              file.)

Okay?

>>        The delegater should not change the ownership  of  any  of  the
>>        controller  interfaces  files  (e.g., pids.max, memory.high) in
>>        dlgt_grp.  Those files are used from the next level  above  the
>>        delegated  subtree  in  order  to distribute resources into the
>>        subtree, and the delegatee should not have permission to change
>>        the resources that are distributed into the delegated subtree.
> 
> Roman recently added /sys/kernel/cgroup/delegate and
> /sys/kernel/cgroup/features.  The former contains newline separated
> list of cgroup files which should be chowned on delegation (in
> addition to the directory itself) and the latter contains optional
> features (currently only nsdelegate).  

Oh -- and this reminds that I've been meaning to ask you for a while
now: could you please (please please please) CC all cgroup interface
changes to linux-api@vger.kernel.org (and prod others to do so
please). There have been many of these changes in recent times
(addition of new v2 controllers, thread mode, nsdelegate, the
changes that Roman made that you refer to above), and they really
all should have been CCed to linux-api@. It's often the only (easy)
way that I have to discover changes that should be documented in
the manual pages. And there are many other groups that are also
interested in tracking kernel-user-space interface changes; see 
https://www.kernel.org/doc/man-pages/linux-api-ml.html

> Roman, can you please update
> cgroup-v2.txt accordingly?

And I've already sent a separate mail re the cgroups(7) changes
relating to /sys/kernel/cgroup/*

> The file list was added because the cgroup OOM support added a knob
> which belongs to the cgroup itself rather than the parent and we might
> have more of those files in the future (not too likely and there won't
> be many).
> 
> It could be also worthwhile to describe nsdelegate, which prevents
> cgroup-namespaced delegatee, which may have the same UID as the
> delegator, from writing to interface files in its cgroup root which
> belong to the parent.

Yes. See my separate mail.

>>        Some delegation containment rules ensure that the delegatee can
>>        move processes between cgroups within  the  delegated  subtree,
>>        but  can't  move  processes  from outside the delegated subtree
>>        into the subtree or vice versa.  A nonprivileged process (i.e.,
>>        the  delegatee)  can write the PID of a "target" process into a
>>        cgroup.procs file only if all of the following are true:
>>
>>        *  The effective  UID  of  the  writer  (i.e.,  the  delegatee)
>>           matches  the  real  user  ID or the saved set-user-ID of the
>>           target process.
> 
> cgroup2 doesn't check the above anymore.

Please please see my request regarding linux-api@ :-)

I see the change was in 4.11, commit 576dd464505fc53d501bb94569db76f220104d28

I rewrote that rule as follows, and moved it to the end of the list (i.e.,
the point XXX below):

       *  Before Linux 4.11: the effective UID of the writer  (i.e.,  the
          delegatee) matches the real user ID or the saved set-user-ID of
          the target process.  (This was a historical requirement  inher‐
          ited  from  cgroups v1 that was later deemed unnecessary, since
          the other rules suffice for containment in cgroups v2.)

>>        *  The writer has write permission on the cgroup.procs file  in
>>           the destination cgroup.
>>
>>        *  The  writer has write permission on the cgroup.procs file in
>>           the common ancestor of the source and  destination  cgroups.
>>           (In  some  cases,  the  common ancestor may be the source or
>>           destination cgroup itself.)
>

> Also, if nsdelegate is enabled, both the source and destination
> cgroups must be visible (cgroup namespace-wise) to the writer.

I added the following:

       *  If  the  cgroup  v2  filesystem was mounted with the nsdelegate
          option, the writer must be able to see the source and  destina‐
          tion cgroup from its cgroup namespace.

Okay?

XXX

> 
>>           ┌─────────────────────────────────────────────────────┐
>>           │FIXME                                                │
>>           ├─────────────────────────────────────────────────────┤
>>           │Please confirm that the following is correct:        │
>>           └─────────────────────────────────────────────────────┘
>>
>>        Note: one consequence of these delegation containment rules  is
>>        that  the  unprivileged delegatee can't place the first process
>>        into the delegated subtree; instead, the delegater  must  place
>>        the  first  process (a process owned by the delegatee) into the
>>        delegated subtree.
> 
> Yeah, that'd be the case.  Seeding of a delegated subtree should be
> done by the delegator or before the priviledges are dropped.

Thanks for the confirmation.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/08/2018 03:14 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Tue, Jan 02, 2018 at 07:22:05PM +0100, Michael Kerrisk (man-pages) wrote:
>>        To perform delegation, the delegater makes certain  directories
>>        and  files writable by the delegatee, typically by changing the
>>        ownership of the objects to be the user ID  of  the  delegatee.
>>        Assuming that we want to delegate the hierarchy rooted at (say)
>>        /dlgt_grp and that there are not yet any  child  cgroups  under
>>        that  cgroup,  the ownership of the following is changed to the
>>        user ID of the delegatee:
>>
>>        /dlgt_grp
>>               Changing the ownership of the root of the subtree  means
>>               that  any new cgroups created under the subtree (and the
>>               files they contain) will also be owned by the delegatee.
>>
>>        /dlgt_grp/cgroup.procs
>>               Changing the ownership of this file means that the dele‐
>>               gatee  can move processes into the root of the delegated
>>               subtree.
>>
>>        /dlgt_grp/cgroup.subtree_control
>>               Making this file owned by  the  delegatee  is  optional.
>>               Doing  so  means that that the delegatee can enable con‐
>>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
>>               trollers)  in order to further redistribute resources at
>>               lower levels in  the  subtree.   As  an  alternative  to
>>               changing the ownership of this file, the delegater might
>>               instead add selected controllers to this file.
> 
> I'm not sure how useful it is to describe this to be optional.  In the
> same sense, cgroup.procs would be optional too as the delegatee can
> take control from its first children.  Users of course can choose to
> do mix and match as they see fit but outside of the defined model,
> there can be surprises - e.g. nsdelegate or some future delegation
> aware feature can behave differently.  I think it'd be better to keep
> it simple - either a subtree is delegated or not.

So, I changed that piece to:

       /dlgt_grp/cgroup.subtree_control
              Changing the ownership of this file  means  that  that  the
              delegatee  can  enable  controllers  (that  are  present in
              /dlgt_grp/cgroup.controllers) in order  to  further  redis‐
              tribute  resources  at lower levels in the subtree.  (As an
              alternative to changing the ownership  of  this  file,  the
              delegater  might  instead  add selected controllers to this
              file.)

Okay?

>>        The delegater should not change the ownership  of  any  of  the
>>        controller  interfaces  files  (e.g., pids.max, memory.high) in
>>        dlgt_grp.  Those files are used from the next level  above  the
>>        delegated  subtree  in  order  to distribute resources into the
>>        subtree, and the delegatee should not have permission to change
>>        the resources that are distributed into the delegated subtree.
> 
> Roman recently added /sys/kernel/cgroup/delegate and
> /sys/kernel/cgroup/features.  The former contains newline separated
> list of cgroup files which should be chowned on delegation (in
> addition to the directory itself) and the latter contains optional
> features (currently only nsdelegate).  

Oh -- and this reminds that I've been meaning to ask you for a while
now: could you please (please please please) CC all cgroup interface
changes to linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (and prod others to do so
please). There have been many of these changes in recent times
(addition of new v2 controllers, thread mode, nsdelegate, the
changes that Roman made that you refer to above), and they really
all should have been CCed to linux-api@. It's often the only (easy)
way that I have to discover changes that should be documented in
the manual pages. And there are many other groups that are also
interested in tracking kernel-user-space interface changes; see 
https://www.kernel.org/doc/man-pages/linux-api-ml.html

> Roman, can you please update
> cgroup-v2.txt accordingly?

And I've already sent a separate mail re the cgroups(7) changes
relating to /sys/kernel/cgroup/*

> The file list was added because the cgroup OOM support added a knob
> which belongs to the cgroup itself rather than the parent and we might
> have more of those files in the future (not too likely and there won't
> be many).
> 
> It could be also worthwhile to describe nsdelegate, which prevents
> cgroup-namespaced delegatee, which may have the same UID as the
> delegator, from writing to interface files in its cgroup root which
> belong to the parent.

Yes. See my separate mail.

>>        Some delegation containment rules ensure that the delegatee can
>>        move processes between cgroups within  the  delegated  subtree,
>>        but  can't  move  processes  from outside the delegated subtree
>>        into the subtree or vice versa.  A nonprivileged process (i.e.,
>>        the  delegatee)  can write the PID of a "target" process into a
>>        cgroup.procs file only if all of the following are true:
>>
>>        *  The effective  UID  of  the  writer  (i.e.,  the  delegatee)
>>           matches  the  real  user  ID or the saved set-user-ID of the
>>           target process.
> 
> cgroup2 doesn't check the above anymore.

Please please see my request regarding linux-api@ :-)

I see the change was in 4.11, commit 576dd464505fc53d501bb94569db76f220104d28

I rewrote that rule as follows, and moved it to the end of the list (i.e.,
the point XXX below):

       *  Before Linux 4.11: the effective UID of the writer  (i.e.,  the
          delegatee) matches the real user ID or the saved set-user-ID of
          the target process.  (This was a historical requirement  inher‐
          ited  from  cgroups v1 that was later deemed unnecessary, since
          the other rules suffice for containment in cgroups v2.)

>>        *  The writer has write permission on the cgroup.procs file  in
>>           the destination cgroup.
>>
>>        *  The  writer has write permission on the cgroup.procs file in
>>           the common ancestor of the source and  destination  cgroups.
>>           (In  some  cases,  the  common ancestor may be the source or
>>           destination cgroup itself.)
>

> Also, if nsdelegate is enabled, both the source and destination
> cgroups must be visible (cgroup namespace-wise) to the writer.

I added the following:

       *  If  the  cgroup  v2  filesystem was mounted with the nsdelegate
          option, the writer must be able to see the source and  destina‐
          tion cgroup from its cgroup namespace.

Okay?

XXX

> 
>>           ┌─────────────────────────────────────────────────────┐
>>           │FIXME                                                │
>>           ├─────────────────────────────────────────────────────┤
>>           │Please confirm that the following is correct:        │
>>           └─────────────────────────────────────────────────────┘
>>
>>        Note: one consequence of these delegation containment rules  is
>>        that  the  unprivileged delegatee can't place the first process
>>        into the delegated subtree; instead, the delegater  must  place
>>        the  first  process (a process owned by the delegatee) into the
>>        delegated subtree.
> 
> Yeah, that'd be the case.  Seeding of a delegated subtree should be
> done by the delegator or before the priviledges are dropped.

Thanks for the confirmation.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello,

On Tue, Jan 09, 2018 at 12:27:58AM +0100, Michael Kerrisk (man-pages) wrote:
> >>        /dlgt_grp/cgroup.subtree_control
> >>               Making this file owned by  the  delegatee  is  optional.
> >>               Doing  so  means that that the delegatee can enable con‐
> >>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
> >>               trollers)  in order to further redistribute resources at
> >>               lower levels in  the  subtree.   As  an  alternative  to
> >>               changing the ownership of this file, the delegater might
> >>               instead add selected controllers to this file.
> > 
> > I'm not sure how useful it is to describe this to be optional.  In the
> > same sense, cgroup.procs would be optional too as the delegatee can
> > take control from its first children.  Users of course can choose to
> > do mix and match as they see fit but outside of the defined model,
> > there can be surprises - e.g. nsdelegate or some future delegation
> > aware feature can behave differently.  I think it'd be better to keep
> > it simple - either a subtree is delegated or not.
> 
> So, I changed that piece to:
> 
>        /dlgt_grp/cgroup.subtree_control
>               Changing the ownership of this file  means  that  that  the
>               delegatee  can  enable  controllers  (that  are  present in
>               /dlgt_grp/cgroup.controllers) in order  to  further  redis‐
>               tribute  resources  at lower levels in the subtree.  (As an
>               alternative to changing the ownership  of  this  file,  the
>               delegater  might  instead  add selected controllers to this
>               file.)
> 
> Okay?

I haven't thought much about not giving out cgroup.subtree_control
when delegating.  It's probably okay but there can be surprises -
e.g. systemd or other agent failing to init resource control because
it failed to write to subtree_control at root.

Also, given that the recommended way to delegate is now chown all
files in the /sys/kernel/cgroup/delegate file it's a bit weird to
single out subtree_control.

That said, not necessarily an objection.  I'm just not sure about it.

> > Roman recently added /sys/kernel/cgroup/delegate and
> > /sys/kernel/cgroup/features.  The former contains newline separated
> > list of cgroup files which should be chowned on delegation (in
> > addition to the directory itself) and the latter contains optional
> > features (currently only nsdelegate).  
> 
> Oh -- and this reminds that I've been meaning to ask you for a while
> now: could you please (please please please) CC all cgroup interface
> changes to linux-api@vger.kernel.org (and prod others to do so
> please). There have been many of these changes in recent times
> (addition of new v2 controllers, thread mode, nsdelegate, the
> changes that Roman made that you refer to above), and they really
> all should have been CCed to linux-api@. It's often the only (easy)
> way that I have to discover changes that should be documented in
> the manual pages. And there are many other groups that are also
> interested in tracking kernel-user-space interface changes; see 
> https://www.kernel.org/doc/man-pages/linux-api-ml.html

Sorry about having not added them before.  Will try to.  Please feel
free to scream at me if I forget.

> > Also, if nsdelegate is enabled, both the source and destination
> > cgroups must be visible (cgroup namespace-wise) to the writer.
> 
> I added the following:
> 
>        *  If  the  cgroup  v2  filesystem was mounted with the nsdelegate
>           option, the writer must be able to see the source and  destina‐
>           tion cgroup from its cgroup namespace.
> 
> Okay?

Yeah, thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello,

On Tue, Jan 09, 2018 at 12:27:58AM +0100, Michael Kerrisk (man-pages) wrote:
> >>        /dlgt_grp/cgroup.subtree_control
> >>               Making this file owned by  the  delegatee  is  optional.
> >>               Doing  so  means that that the delegatee can enable con‐
> >>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
> >>               trollers)  in order to further redistribute resources at
> >>               lower levels in  the  subtree.   As  an  alternative  to
> >>               changing the ownership of this file, the delegater might
> >>               instead add selected controllers to this file.
> > 
> > I'm not sure how useful it is to describe this to be optional.  In the
> > same sense, cgroup.procs would be optional too as the delegatee can
> > take control from its first children.  Users of course can choose to
> > do mix and match as they see fit but outside of the defined model,
> > there can be surprises - e.g. nsdelegate or some future delegation
> > aware feature can behave differently.  I think it'd be better to keep
> > it simple - either a subtree is delegated or not.
> 
> So, I changed that piece to:
> 
>        /dlgt_grp/cgroup.subtree_control
>               Changing the ownership of this file  means  that  that  the
>               delegatee  can  enable  controllers  (that  are  present in
>               /dlgt_grp/cgroup.controllers) in order  to  further  redis‐
>               tribute  resources  at lower levels in the subtree.  (As an
>               alternative to changing the ownership  of  this  file,  the
>               delegater  might  instead  add selected controllers to this
>               file.)
> 
> Okay?

I haven't thought much about not giving out cgroup.subtree_control
when delegating.  It's probably okay but there can be surprises -
e.g. systemd or other agent failing to init resource control because
it failed to write to subtree_control at root.

Also, given that the recommended way to delegate is now chown all
files in the /sys/kernel/cgroup/delegate file it's a bit weird to
single out subtree_control.

That said, not necessarily an objection.  I'm just not sure about it.

> > Roman recently added /sys/kernel/cgroup/delegate and
> > /sys/kernel/cgroup/features.  The former contains newline separated
> > list of cgroup files which should be chowned on delegation (in
> > addition to the directory itself) and the latter contains optional
> > features (currently only nsdelegate).  
> 
> Oh -- and this reminds that I've been meaning to ask you for a while
> now: could you please (please please please) CC all cgroup interface
> changes to linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (and prod others to do so
> please). There have been many of these changes in recent times
> (addition of new v2 controllers, thread mode, nsdelegate, the
> changes that Roman made that you refer to above), and they really
> all should have been CCed to linux-api@. It's often the only (easy)
> way that I have to discover changes that should be documented in
> the manual pages. And there are many other groups that are also
> interested in tracking kernel-user-space interface changes; see 
> https://www.kernel.org/doc/man-pages/linux-api-ml.html

Sorry about having not added them before.  Will try to.  Please feel
free to scream at me if I forget.

> > Also, if nsdelegate is enabled, both the source and destination
> > cgroups must be visible (cgroup namespace-wise) to the writer.
> 
> I added the following:
> 
>        *  If  the  cgroup  v2  filesystem was mounted with the nsdelegate
>           option, the writer must be able to see the source and  destina‐
>           tion cgroup from its cgroup namespace.
> 
> Okay?

Yeah, thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/09/2018 10:07 PM, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 09, 2018 at 12:27:58AM +0100, Michael Kerrisk (man-pages) wrote:
>>>>        /dlgt_grp/cgroup.subtree_control
>>>>               Making this file owned by  the  delegatee  is  optional.
>>>>               Doing  so  means that that the delegatee can enable con‐
>>>>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
>>>>               trollers)  in order to further redistribute resources at
>>>>               lower levels in  the  subtree.   As  an  alternative  to
>>>>               changing the ownership of this file, the delegater might
>>>>               instead add selected controllers to this file.
>>>
>>> I'm not sure how useful it is to describe this to be optional.  In the
>>> same sense, cgroup.procs would be optional too as the delegatee can
>>> take control from its first children.  Users of course can choose to
>>> do mix and match as they see fit but outside of the defined model,
>>> there can be surprises - e.g. nsdelegate or some future delegation
>>> aware feature can behave differently.  I think it'd be better to keep
>>> it simple - either a subtree is delegated or not.
>>
>> So, I changed that piece to:
>>
>>        /dlgt_grp/cgroup.subtree_control
>>               Changing the ownership of this file  means  that  that  the
>>               delegatee  can  enable  controllers  (that  are  present in
>>               /dlgt_grp/cgroup.controllers) in order  to  further  redis‐
>>               tribute  resources  at lower levels in the subtree.  (As an
>>               alternative to changing the ownership  of  this  file,  the
>>               delegater  might  instead  add selected controllers to this
>>               file.)
>>
>> Okay?
> 
> I haven't thought much about not giving out cgroup.subtree_control
> when delegating.  It's probably okay but there can be surprises -
> e.g. systemd or other agent failing to init resource control because
> it failed to write to subtree_control at root.
> 
> Also, given that the recommended way to delegate is now chown all
> files in the /sys/kernel/cgroup/delegate file it's a bit weird to
> single out subtree_control.

I guess the point here is that it really makes no sense not to
change ownership of cgroup.procs. On the other hand, if
ownership of cgroup.subtree_control is not handed to the
delegatee, then the delegater can choose which controllers the
delegatee will be allowed to exercise, by writing only those
controllers into cgroup.subtree_control. I'm not sure if
there's a use case though.

> That said, not necessarily an objection.  I'm just not sure about it.

Okay. For the moment, I'll leave that text as is.

I realized that there was also one more file that needs to be included
in the list of files that must be delegated:

       /dlgt_grp/cgroup.threads
              Changing the ownership of  this  file  is  necessary  if  a
              threaded subtree is being delegated (see the description of
              "thread mode", below).

Can you please confirm that it's only necessary to delegate this file
if we are delegating a threaded subtree?

>>> Roman recently added /sys/kernel/cgroup/delegate and
>>> /sys/kernel/cgroup/features.  The former contains newline separated
>>> list of cgroup files which should be chowned on delegation (in
>>> addition to the directory itself) and the latter contains optional
>>> features (currently only nsdelegate).  
>>
>> Oh -- and this reminds that I've been meaning to ask you for a while
>> now: could you please (please please please) CC all cgroup interface
>> changes to linux-api@vger.kernel.org (and prod others to do so
>> please). There have been many of these changes in recent times
>> (addition of new v2 controllers, thread mode, nsdelegate, the
>> changes that Roman made that you refer to above), and they really
>> all should have been CCed to linux-api@. It's often the only (easy)
>> way that I have to discover changes that should be documented in
>> the manual pages. And there are many other groups that are also
>> interested in tracking kernel-user-space interface changes; see 
>> https://www.kernel.org/doc/man-pages/linux-api-ml.html
> 
> Sorry about having not added them before.  Will try to.  Please feel
> free to scream at me if I forget.

Okay. (Except I may not not e when you forget ;-).)
 
>>> Also, if nsdelegate is enabled, both the source and destination
>>> cgroups must be visible (cgroup namespace-wise) to the writer.
>>
>> I added the following:
>>
>>        *  If  the  cgroup  v2  filesystem was mounted with the nsdelegate
>>           option, the writer must be able to see the source and  destina‐
>>           tion cgroup from its cgroup namespace.
>>
>> Okay?
> 
> Yeah, thanks.

Thanks for checking the text, Tejun!

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/09/2018 10:07 PM, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 09, 2018 at 12:27:58AM +0100, Michael Kerrisk (man-pages) wrote:
>>>>        /dlgt_grp/cgroup.subtree_control
>>>>               Making this file owned by  the  delegatee  is  optional.
>>>>               Doing  so  means that that the delegatee can enable con‐
>>>>               trollers  (that  are  present  in  /dlgt_grp/cgroup.con‐
>>>>               trollers)  in order to further redistribute resources at
>>>>               lower levels in  the  subtree.   As  an  alternative  to
>>>>               changing the ownership of this file, the delegater might
>>>>               instead add selected controllers to this file.
>>>
>>> I'm not sure how useful it is to describe this to be optional.  In the
>>> same sense, cgroup.procs would be optional too as the delegatee can
>>> take control from its first children.  Users of course can choose to
>>> do mix and match as they see fit but outside of the defined model,
>>> there can be surprises - e.g. nsdelegate or some future delegation
>>> aware feature can behave differently.  I think it'd be better to keep
>>> it simple - either a subtree is delegated or not.
>>
>> So, I changed that piece to:
>>
>>        /dlgt_grp/cgroup.subtree_control
>>               Changing the ownership of this file  means  that  that  the
>>               delegatee  can  enable  controllers  (that  are  present in
>>               /dlgt_grp/cgroup.controllers) in order  to  further  redis‐
>>               tribute  resources  at lower levels in the subtree.  (As an
>>               alternative to changing the ownership  of  this  file,  the
>>               delegater  might  instead  add selected controllers to this
>>               file.)
>>
>> Okay?
> 
> I haven't thought much about not giving out cgroup.subtree_control
> when delegating.  It's probably okay but there can be surprises -
> e.g. systemd or other agent failing to init resource control because
> it failed to write to subtree_control at root.
> 
> Also, given that the recommended way to delegate is now chown all
> files in the /sys/kernel/cgroup/delegate file it's a bit weird to
> single out subtree_control.

I guess the point here is that it really makes no sense not to
change ownership of cgroup.procs. On the other hand, if
ownership of cgroup.subtree_control is not handed to the
delegatee, then the delegater can choose which controllers the
delegatee will be allowed to exercise, by writing only those
controllers into cgroup.subtree_control. I'm not sure if
there's a use case though.

> That said, not necessarily an objection.  I'm just not sure about it.

Okay. For the moment, I'll leave that text as is.

I realized that there was also one more file that needs to be included
in the list of files that must be delegated:

       /dlgt_grp/cgroup.threads
              Changing the ownership of  this  file  is  necessary  if  a
              threaded subtree is being delegated (see the description of
              "thread mode", below).

Can you please confirm that it's only necessary to delegate this file
if we are delegating a threaded subtree?

>>> Roman recently added /sys/kernel/cgroup/delegate and
>>> /sys/kernel/cgroup/features.  The former contains newline separated
>>> list of cgroup files which should be chowned on delegation (in
>>> addition to the directory itself) and the latter contains optional
>>> features (currently only nsdelegate).  
>>
>> Oh -- and this reminds that I've been meaning to ask you for a while
>> now: could you please (please please please) CC all cgroup interface
>> changes to linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (and prod others to do so
>> please). There have been many of these changes in recent times
>> (addition of new v2 controllers, thread mode, nsdelegate, the
>> changes that Roman made that you refer to above), and they really
>> all should have been CCed to linux-api@. It's often the only (easy)
>> way that I have to discover changes that should be documented in
>> the manual pages. And there are many other groups that are also
>> interested in tracking kernel-user-space interface changes; see 
>> https://www.kernel.org/doc/man-pages/linux-api-ml.html
> 
> Sorry about having not added them before.  Will try to.  Please feel
> free to scream at me if I forget.

Okay. (Except I may not not e when you forget ;-).)
 
>>> Also, if nsdelegate is enabled, both the source and destination
>>> cgroups must be visible (cgroup namespace-wise) to the writer.
>>
>> I added the following:
>>
>>        *  If  the  cgroup  v2  filesystem was mounted with the nsdelegate
>>           option, the writer must be able to see the source and  destina‐
>>           tion cgroup from its cgroup namespace.
>>
>> Okay?
> 
> Yeah, thanks.

Thanks for checking the text, Tejun!

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello, Michael.

On Tue, Jan 09, 2018 at 11:48:11PM +0100, Michael Kerrisk (man-pages) wrote:
> > That said, not necessarily an objection.  I'm just not sure about it.
> 
> Okay. For the moment, I'll leave that text as is.
> 
> I realized that there was also one more file that needs to be included
> in the list of files that must be delegated:
> 
>        /dlgt_grp/cgroup.threads
>               Changing the ownership of  this  file  is  necessary  if  a
>               threaded subtree is being delegated (see the description of
>               "thread mode", below).
> 
> Can you please confirm that it's only necessary to delegate this file
> if we are delegating a threaded subtree?

Replied on the other thread.  The file isn't delegatable as far as I
can tell.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello, Michael.

On Tue, Jan 09, 2018 at 11:48:11PM +0100, Michael Kerrisk (man-pages) wrote:
> > That said, not necessarily an objection.  I'm just not sure about it.
> 
> Okay. For the moment, I'll leave that text as is.
> 
> I realized that there was also one more file that needs to be included
> in the list of files that must be delegated:
> 
>        /dlgt_grp/cgroup.threads
>               Changing the ownership of  this  file  is  necessary  if  a
>               threaded subtree is being delegated (see the description of
>               "thread mode", below).
> 
> Can you please confirm that it's only necessary to delegate this file
> if we are delegating a threaded subtree?

Replied on the other thread.  The file isn't delegatable as far as I
can tell.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/10/2018 03:26 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Tue, Jan 09, 2018 at 11:48:11PM +0100, Michael Kerrisk (man-pages) wrote:
>>> That said, not necessarily an objection.  I'm just not sure about it.
>>
>> Okay. For the moment, I'll leave that text as is.
>>
>> I realized that there was also one more file that needs to be included
>> in the list of files that must be delegated:
>>
>>        /dlgt_grp/cgroup.threads
>>               Changing the ownership of  this  file  is  necessary  if  a
>>               threaded subtree is being delegated (see the description of
>>               "thread mode", below).
>>
>> Can you please confirm that it's only necessary to delegate this file
>> if we are delegating a threaded subtree?
> 
> Replied on the other thread.  The file isn't delegatable as far as I
> can tell.

So, following on from the discussion in the other thread, my
question above still stands.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/10/2018 03:26 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Tue, Jan 09, 2018 at 11:48:11PM +0100, Michael Kerrisk (man-pages) wrote:
>>> That said, not necessarily an objection.  I'm just not sure about it.
>>
>> Okay. For the moment, I'll leave that text as is.
>>
>> I realized that there was also one more file that needs to be included
>> in the list of files that must be delegated:
>>
>>        /dlgt_grp/cgroup.threads
>>               Changing the ownership of  this  file  is  necessary  if  a
>>               threaded subtree is being delegated (see the description of
>>               "thread mode", below).
>>
>> Can you please confirm that it's only necessary to delegate this file
>> if we are delegating a threaded subtree?
> 
> Replied on the other thread.  The file isn't delegatable as far as I
> can tell.

So, following on from the discussion in the other thread, my
question above still stands.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello,

On Wed, Jan 10, 2018 at 08:20:53PM +0100, Michael Kerrisk (man-pages) wrote:
> On 01/10/2018 03:26 PM, Tejun Heo wrote:
> > Hello, Michael.
> > 
> > On Tue, Jan 09, 2018 at 11:48:11PM +0100, Michael Kerrisk (man-pages) wrote:
> >>> That said, not necessarily an objection.  I'm just not sure about it.
> >>
> >> Okay. For the moment, I'll leave that text as is.
> >>
> >> I realized that there was also one more file that needs to be included
> >> in the list of files that must be delegated:
> >>
> >>        /dlgt_grp/cgroup.threads
> >>               Changing the ownership of  this  file  is  necessary  if  a
> >>               threaded subtree is being delegated (see the description of
> >>               "thread mode", below).
> >>
> >> Can you please confirm that it's only necessary to delegate this file
> >> if we are delegating a threaded subtree?
> > 
> > Replied on the other thread.  The file isn't delegatable as far as I
> > can tell.
> 
> So, following on from the discussion in the other thread, my
> question above still stands.

Oh, I frankly haven't thought about delegating a threaded subtree.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/10/2018 08:39 PM, Tejun Heo wrote:
> Hello,
> 
> On Wed, Jan 10, 2018 at 08:20:53PM +0100, Michael Kerrisk (man-pages) wrote:
>> On 01/10/2018 03:26 PM, Tejun Heo wrote:
>>> Hello, Michael.
>>>
>>> On Tue, Jan 09, 2018 at 11:48:11PM +0100, Michael Kerrisk (man-pages) wrote:
>>>>> That said, not necessarily an objection.  I'm just not sure about it.
>>>>
>>>> Okay. For the moment, I'll leave that text as is.
>>>>
>>>> I realized that there was also one more file that needs to be included
>>>> in the list of files that must be delegated:
>>>>
>>>>        /dlgt_grp/cgroup.threads
>>>>               Changing the ownership of  this  file  is  necessary  if  a
>>>>               threaded subtree is being delegated (see the description of
>>>>               "thread mode", below).
>>>>
>>>> Can you please confirm that it's only necessary to delegate this file
>>>> if we are delegating a threaded subtree?
>>>
>>> Replied on the other thread.  The file isn't delegatable as far as I
>>> can tell.
>>
>> So, following on from the discussion in the other thread, my
>> question above still stands.
> 
> Oh, I frankly haven't thought about delegating a threaded subtree.

I'm still confused. cgroup-v2.txt documents the possibility. You
wrote that text. We just had a conversation in another thread about the
fact that cgroup.threads is delegatable. You must have thought at 
least a little about this?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello, Michael.

On Wed, Jan 10, 2018 at 11:01:11PM +0100, Michael Kerrisk (man-pages) wrote:
> >>>> Can you please confirm that it's only necessary to delegate this file
> >>>> if we are delegating a threaded subtree?
> >>>
> >>> Replied on the other thread.  The file isn't delegatable as far as I
> >>> can tell.
> >>
> >> So, following on from the discussion in the other thread, my
> >> question above still stands.
> > 
> > Oh, I frankly haven't thought about delegating a threaded subtree.
> 
> I'm still confused. cgroup-v2.txt documents the possibility. You
> wrote that text. We just had a conversation in another thread about the
> fact that cgroup.threads is delegatable. You must have thought at 
> least a little about this?

Oh, I'm probably mixing up two things.

1. When delegating, cgroup.threads should be delegated.  Doing that
   selectively doesn't achieve anything meaningful.

2. I haven't thought much about delegating a sub-protion of a threaded
   subtree.  Everything works the same way.  I just can't think of a
   use case.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello, Michael.

On Wed, Jan 10, 2018 at 11:01:11PM +0100, Michael Kerrisk (man-pages) wrote:
> >>>> Can you please confirm that it's only necessary to delegate this file
> >>>> if we are delegating a threaded subtree?
> >>>
> >>> Replied on the other thread.  The file isn't delegatable as far as I
> >>> can tell.
> >>
> >> So, following on from the discussion in the other thread, my
> >> question above still stands.
> > 
> > Oh, I frankly haven't thought about delegating a threaded subtree.
> 
> I'm still confused. cgroup-v2.txt documents the possibility. You
> wrote that text. We just had a conversation in another thread about the
> fact that cgroup.threads is delegatable. You must have thought at 
> least a little about this?

Oh, I'm probably mixing up two things.

1. When delegating, cgroup.threads should be delegated.  Doing that
   selectively doesn't achieve anything meaningful.

2. I haven't thought much about delegating a sub-protion of a threaded
   subtree.  Everything works the same way.  I just can't think of a
   use case.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/10/2018 11:14 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Wed, Jan 10, 2018 at 11:01:11PM +0100, Michael Kerrisk (man-pages) wrote:
>>>>>> Can you please confirm that it's only necessary to delegate this file
>>>>>> if we are delegating a threaded subtree?
>>>>>
>>>>> Replied on the other thread.  The file isn't delegatable as far as I
>>>>> can tell.
>>>>
>>>> So, following on from the discussion in the other thread, my
>>>> question above still stands.
>>>
>>> Oh, I frankly haven't thought about delegating a threaded subtree.
>>
>> I'm still confused. cgroup-v2.txt documents the possibility. You
>> wrote that text. We just had a conversation in another thread about the
>> fact that cgroup.threads is delegatable. You must have thought at 
>> least a little about this?
> 
> Oh, I'm probably mixing up two things.
> 
> 1. When delegating, cgroup.threads should be delegated.  Doing that
>    selectively doesn't achieve anything meaningful.

Understood. But surely delegating cgroup.threads is effectively
meaningless when delegating a "domain" cgroup tree? (Obviously it's
not harmful to delegate the the cgroup.threads file in this case;
it's just not useful to do so.)

> 2. I haven't thought much about delegating a sub-protion of a threaded
>    subtree.  Everything works the same way.  I just can't think of a
>    use case.

Ahhh -- now I see what you meant before.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

Hello Tejun,

On 01/10/2018 11:14 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Wed, Jan 10, 2018 at 11:01:11PM +0100, Michael Kerrisk (man-pages) wrote:
>>>>>> Can you please confirm that it's only necessary to delegate this file
>>>>>> if we are delegating a threaded subtree?
>>>>>
>>>>> Replied on the other thread.  The file isn't delegatable as far as I
>>>>> can tell.
>>>>
>>>> So, following on from the discussion in the other thread, my
>>>> question above still stands.
>>>
>>> Oh, I frankly haven't thought about delegating a threaded subtree.
>>
>> I'm still confused. cgroup-v2.txt documents the possibility. You
>> wrote that text. We just had a conversation in another thread about the
>> fact that cgroup.threads is delegatable. You must have thought at 
>> least a little about this?
> 
> Oh, I'm probably mixing up two things.
> 
> 1. When delegating, cgroup.threads should be delegated.  Doing that
>    selectively doesn't achieve anything meaningful.

Understood. But surely delegating cgroup.threads is effectively
meaningless when delegating a "domain" cgroup tree? (Obviously it's
not harmful to delegate the the cgroup.threads file in this case;
it's just not useful to do so.)

> 2. I haven't thought much about delegating a sub-protion of a threaded
>    subtree.  Everything works the same way.  I just can't think of a
>    use case.

Ahhh -- now I see what you meant before.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello,

On Wed, Jan 10, 2018 at 11:24:05PM +0100, Michael Kerrisk (man-pages) wrote:
> > Oh, I'm probably mixing up two things.
> > 
> > 1. When delegating, cgroup.threads should be delegated.  Doing that
> >    selectively doesn't achieve anything meaningful.
> 
> Understood. But surely delegating cgroup.threads is effectively
> meaningless when delegating a "domain" cgroup tree? (Obviously it's
> not harmful to delegate the the cgroup.threads file in this case;
> it's just not useful to do so.)

Yeap, unless we can somehow support non-root mixed domains.

Thanks.

-- 
tejun

Re: cgroups(7): documenting cgroups v2 delegation

[Tejun Heo]

Hello,

On Wed, Jan 10, 2018 at 11:24:05PM +0100, Michael Kerrisk (man-pages) wrote:
> > Oh, I'm probably mixing up two things.
> > 
> > 1. When delegating, cgroup.threads should be delegated.  Doing that
> >    selectively doesn't achieve anything meaningful.
> 
> Understood. But surely delegating cgroup.threads is effectively
> meaningless when delegating a "domain" cgroup tree? (Obviously it's
> not harmful to delegate the the cgroup.threads file in this case;
> it's just not useful to do so.)

Yeap, unless we can somehow support non-root mixed domains.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

On 01/10/2018 11:27 PM, Tejun Heo wrote:
> Hello,
> 
> On Wed, Jan 10, 2018 at 11:24:05PM +0100, Michael Kerrisk (man-pages) wrote:
>>> Oh, I'm probably mixing up two things.
>>>
>>> 1. When delegating, cgroup.threads should be delegated.  Doing that
>>>    selectively doesn't achieve anything meaningful.
>>
>> Understood. But surely delegating cgroup.threads is effectively
>> meaningless when delegating a "domain" cgroup tree? (Obviously it's
>> not harmful to delegate the the cgroup.threads file in this case;
>> it's just not useful to do so.)
> 
> Yeap, unless we can somehow support non-root mixed domains.

Thanks for the clarification/confirmation, Tejun.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroups v2 delegation

[Michael Kerrisk (man-pages)]

On 01/10/2018 11:27 PM, Tejun Heo wrote:
> Hello,
> 
> On Wed, Jan 10, 2018 at 11:24:05PM +0100, Michael Kerrisk (man-pages) wrote:
>>> Oh, I'm probably mixing up two things.
>>>
>>> 1. When delegating, cgroup.threads should be delegated.  Doing that
>>>    selectively doesn't achieve anything meaningful.
>>
>> Understood. But surely delegating cgroup.threads is effectively
>> meaningless when delegating a "domain" cgroup tree? (Obviously it's
>> not harmful to delegate the the cgroup.threads file in this case;
>> it's just not useful to do so.)
> 
> Yeap, unless we can somehow support non-root mixed domains.

Thanks for the clarification/confirmation, Tejun.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html