* Issue in man page cgroup_namespaces.7
@ 2022-03-13 12:34 Helge Kreutzmann
0 siblings, 0 replies; 8+ messages in thread
From: Helge Kreutzmann @ 2022-03-13 12:34 UTC (permalink / raw)
To: mtk.manpages; +Cc: mario.blaettermann, linux-man
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."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Issue in man page cgroup_namespaces.7
@ 2022-12-04 9:07 Helge Kreutzmann
2022-12-04 20:07 ` Alejandro Colomar
0 siblings, 1 reply; 8+ messages in thread
From: Helge Kreutzmann @ 2022-12-04 9:07 UTC (permalink / raw)
To: alx.manpages; +Cc: mario.blaettermann, linux-man
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."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue in man page cgroup_namespaces.7
2022-12-04 9:07 Issue in man page cgroup_namespaces.7 Helge Kreutzmann
@ 2022-12-04 20:07 ` Alejandro Colomar
2022-12-04 20:11 ` Helge Kreutzmann
2022-12-05 13:14 ` Jakub Wilk
0 siblings, 2 replies; 8+ messages in thread
From: Alejandro Colomar @ 2022-12-04 20:07 UTC (permalink / raw)
To: Helge Kreutzmann; +Cc: mario.blaettermann, linux-man, G. Branden Robinson
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue in man page cgroup_namespaces.7
2022-12-04 20:07 ` Alejandro Colomar
@ 2022-12-04 20:11 ` Helge Kreutzmann
2022-12-04 21:22 ` Alejandro Colomar
2022-12-05 13:14 ` Jakub Wilk
1 sibling, 1 reply; 8+ messages in thread
From: Helge Kreutzmann @ 2022-12-04 20:11 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: mario.blaettermann, linux-man, G. Branden Robinson
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue in man page cgroup_namespaces.7
2022-12-04 20:11 ` Helge Kreutzmann
@ 2022-12-04 21:22 ` Alejandro Colomar
0 siblings, 0 replies; 8+ messages in thread
From: Alejandro Colomar @ 2022-12-04 21:22 UTC (permalink / raw)
To: Helge Kreutzmann; +Cc: mario.blaettermann, linux-man, G. Branden Robinson
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue in man page cgroup_namespaces.7
2022-12-04 20:07 ` Alejandro Colomar
2022-12-04 20:11 ` Helge Kreutzmann
@ 2022-12-05 13:14 ` Jakub Wilk
1 sibling, 0 replies; 8+ messages in thread
From: Jakub Wilk @ 2022-12-05 13:14 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Helge Kreutzmann, Mario Blättermann, linux-man,
G. Branden Robinson
* 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Issue in man page cgroup_namespaces.7
@ 2025-08-24 14:48 Helge Kreutzmann
2025-09-01 13:39 ` Alejandro Colomar
0 siblings, 1 reply; 8+ messages in thread
From: Helge Kreutzmann @ 2025-08-24 14:48 UTC (permalink / raw)
To: alx; +Cc: mario.blaettermann, linux-man
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"
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issue in man page cgroup_namespaces.7
2025-08-24 14:48 Helge Kreutzmann
@ 2025-09-01 13:39 ` Alejandro Colomar
0 siblings, 0 replies; 8+ messages in thread
From: Alejandro Colomar @ 2025-09-01 13:39 UTC (permalink / raw)
To: Helge Kreutzmann; +Cc: mario.blaettermann, linux-man
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-09-01 13:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-04 9:07 Issue in man page cgroup_namespaces.7 Helge Kreutzmann
2022-12-04 20:07 ` Alejandro Colomar
2022-12-04 20:11 ` Helge Kreutzmann
2022-12-04 21:22 ` Alejandro Colomar
2022-12-05 13:14 ` Jakub Wilk
-- strict thread matches above, loose matches on Subject: below --
2025-08-24 14:48 Helge Kreutzmann
2025-09-01 13:39 ` Alejandro Colomar
2022-03-13 12:34 Helge Kreutzmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox