Issue in man page cgroup_namespaces.7

Issue in man page cgroup_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    user ID → UID

"We have a cgroup directory, I</cg/1>, that is owned by user ID 9000."

"We have a process, I<X>, also owned by user ID 9000, that is namespaced "
"under the cgroup I</cg/1/2> (i.e., I<X> was placed in a new cgroup namespace "
"via B<clone>(2)  or B<unshare>(2)  with the B<CLONE_NEWCGROUP> flag)."

"In the absence of cgroup namespacing, because the cgroup directory I</cg/1> "
"is owned (and writable) by UID 9000 and process I<X> is also owned by user "
"ID 9000, process I<X> would be able to modify the contents of cgroups files "
"(i.e., change cgroup settings) not only in I</cg/1/2> but also in the "
"ancestor cgroup directory I</cg/1>.  Namespacing process I<X> under the "
"cgroup directory I</cg/1/2>, in combination with suitable mount operations "
"for the cgroup filesystem (as shown above), prevents it modifying files in "
"I</cg/1>, since it cannot even see the contents of that directory (or of "
"further removed cgroup ancestor directories).  Combined with correct "
"enforcement of hierarchical limits, this prevents process I<X> from escaping "
"the limits imposed by ancestor cgroups."

"In the absence of cgroup namespacing, because the cgroup directory I</cg/1> "
"is owned (and writable) by UID 9000 and process I<X> is also owned by user "
"ID 9000, then process I<X> would be able to modify the contents of cgroups "
"files (i.e., change cgroup settings) not only in I</cg/1/2> but also in the "
"ancestor cgroup directory I</cg/1>.  Namespacing process I<X> under the "
"cgroup directory I</cg/1/2>, in combination with suitable mount operations "
"for the cgroup filesystem (as shown above), prevents it modifying files in "
"I</cg/1>, since it cannot even see the contents of that directory (or of "
"further removed cgroup ancestor directories).  Combined with correct "
"enforcement of hierarchical limits, this prevents process I<X> from escaping "
"the limits imposed by ancestor cgroups."

Re: Issue in man page cgroup_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2470 bytes --]

Hi Helge,

On 12/4/22 10:07, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    user ID → UID

IMO, (and I believe Branden will agree), user ID is more informative than UID. 
If any change, I'd apply some consistency in the other direction (don't know how 
much inconsistent the pages are regarding that): UID -> user ID.

So, WONTFIX.  Thanks for the reports!

Cheers,

Alex


> 
> "We have a cgroup directory, I</cg/1>, that is owned by user ID 9000." >
> "We have a process, I<X>, also owned by user ID 9000, that is namespaced"
> "under the cgroup I</cg/1/2> (i.e., I<X> was placed in a new cgroup namespace"
> "via B<clone>(2)  or B<unshare>(2)  with the B<CLONE_NEWCGROUP> flag)."
> 
> "In the absence of cgroup namespacing, because the cgroup directory I</cg/1>"
> "is owned (and writable) by UID 9000 and process I<X> is also owned by user"
> "ID 9000, process I<X> would be able to modify the contents of cgroups files"
> "(i.e., change cgroup settings) not only in I</cg/1/2> but also in the"
> "ancestor cgroup directory I</cg/1>.  Namespacing process I<X> under the"
> "cgroup directory I</cg/1/2>, in combination with suitable mount operations"
> "for the cgroup filesystem (as shown above), prevents it modifying files in"
> "I</cg/1>, since it cannot even see the contents of that directory (or of"
> "further removed cgroup ancestor directories).  Combined with correct"
> "enforcement of hierarchical limits, this prevents process I<X> from escaping"
> "the limits imposed by ancestor cgroups."
> 
> "In the absence of cgroup namespacing, because the cgroup directory I</cg/1>"
> "is owned (and writable) by UID 9000 and process I<X> is also owned by user"
> "ID 9000, then process I<X> would be able to modify the contents of cgroups"
> "files (i.e., change cgroup settings) not only in I</cg/1/2> but also in the"
> "ancestor cgroup directory I</cg/1>.  Namespacing process I<X> under the"
> "cgroup directory I</cg/1/2>, in combination with suitable mount operations"
> "for the cgroup filesystem (as shown above), prevents it modifying files in"
> "I</cg/1>, since it cannot even see the contents of that directory (or of"
> "further removed cgroup ancestor directories).  Combined with correct"
> "enforcement of hierarchical limits, this prevents process I<X> from escaping"
> "the limits imposed by ancestor cgroups."

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page cgroup_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

Hello Alejandro,
On Sun, Dec 04, 2022 at 09:07:45PM +0100, Alejandro Colomar wrote:
> On 12/4/22 10:07, Helge Kreutzmann wrote:
> > Without further ado, the following was found:
> > 
> > Issue:    user ID → UID
> 
> IMO, (and I believe Branden will agree), user ID is more informative than
> UID. If any change, I'd apply some consistency in the other direction (don't
> know how much inconsistent the pages are regarding that): UID -> user ID.
> 
> So, WONTFIX.  Thanks for the reports!

Noted.

However, you might consider making the link once, i.e. on first
occurence do
user ID → user ID (UID)

Greetings

         Helge


-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page cgroup_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 839 bytes --]

Hi Helge,

On 12/4/22 21:11, Helge Kreutzmann wrote:
> Hello Alejandro,
> On Sun, Dec 04, 2022 at 09:07:45PM +0100, Alejandro Colomar wrote:
>> On 12/4/22 10:07, Helge Kreutzmann wrote:
>>> Without further ado, the following was found:
>>>
>>> Issue:    user ID → UID
>>
>> IMO, (and I believe Branden will agree), user ID is more informative than
>> UID. If any change, I'd apply some consistency in the other direction (don't
>> know how much inconsistent the pages are regarding that): UID -> user ID.
>>
>> So, WONTFIX.  Thanks for the reports!
> 
> Noted.
> 
> However, you might consider making the link once, i.e. on first
> occurence do
> user ID → user ID (UID)
> 

Yep, I'll do that.  Thanks!

Cheers,

Alex

> Greetings
> 
>           Helge
> 
> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page cgroup_namespaces.7

[Jakub Wilk]

* Alejandro Colomar <alx.manpages@gmail.com>, 2022-12-04 21:07:
>>Issue:    user ID → UID
>
>IMO, (and I believe Branden will agree), user ID is more informative 
>than UID.

FWIW, "user ID" is already documented[*] to be preferred in compounds: 
set-user-ID, set-group-ID (rather than set-UID, set-GID).

>(don't know how much inconsistent the pages are regarding 
>that): UID -> user ID.

AFAICS both terms are widely used.


[*] See man-pages(7), subsection "Preferred terms". 

-- 
Jakub Wilk

Issue in man page cgroup_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    B<Create>aB<process>thatB<lives>forB<a>while → Create a process that lives for a while

"#B< mkdir -p /sys/fs/cgroup/freezer/sub2>;\n"
"#B< sleep 10000 &>#B<Create>aB<process>thatB<lives>forB<a>while\n"
"[1] 20124\n"
"#B< echo 20124 E<gt> /sys/fs/cgroup/freezer/sub2/cgroup.procs>;\n"

Re: Issue in man page cgroup_namespaces.7

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Sun, Aug 24, 2025 at 02:48:33PM +0000, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    B<Create>aB<process>thatB<lives>forB<a>while → Create a process that lives for a while

Fixed; thanks!

> 
> "#B< mkdir -p /sys/fs/cgroup/freezer/sub2>;\n"
> "#B< sleep 10000 &>#B<Create>aB<process>thatB<lives>forB<a>while\n"
> "[1] 20124\n"
> "#B< echo 20124 E<gt> /sys/fs/cgroup/freezer/sub2/cgroup.procs>;\n"
> 

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Issue in man page cgroup_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    user ID → UID

"We have a cgroup directory, I</cg/1>, that is owned by user ID 9000."

"We have a process, I<X>, also owned by user ID 9000, that is namespaced "
"under the cgroup I</cg/1/2> (i.e., I<X> was placed in a new cgroup namespace "
"via B<clone>(2)  or B<unshare>(2)  with the B<CLONE_NEWCGROUP> flag)."

"In the absence of cgroup namespacing, because the cgroup directory I</cg/1> "
"is owned (and writable) by UID 9000 and process I<X> is also owned by user "
"ID 9000, process I<X> would be able to modify the contents of cgroups files "
"(i.e., change cgroup settings) not only in I</cg/1/2> but also in the "
"ancestor cgroup directory I</cg/1>.  Namespacing process I<X> under the "
"cgroup directory I</cg/1/2>, in combination with suitable mount operations "
"for the cgroup filesystem (as shown above), prevents it modifying files in "
"I</cg/1>, since it cannot even see the contents of that directory (or of "
"further removed cgroup ancestor directories).  Combined with correct "
"enforcement of hierarchical limits, this prevents process I<X> from escaping "
"the limits imposed by ancestor cgroups."