Hello Eric,
On 02/11/2015 02:51 PM, Eric W. Biederman wrote:
"Michael Kerrisk (man-pages)" [off-list ref] writes:
quoted
Hi Eric,
Ping!
Cheers,
Michael
My apologies. You description wasn't wrong but it may be a bit
misleading, explanation below. You will have to figure out how to work
that into your proposed text.
quoted
On 2 February 2015 at 16:36, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
[Adding Josh to CC in case he has anything to add.]
On 12/12/2014 10:54 PM, Eric W. Biederman wrote:
quoted
Signed-off-by: Eric W. Biederman <redacted>
---
man5/proc.5 | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/man5/proc.5 b/man5/proc.5
index 96077d0dd195..d661e8cfeac9 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -1097,6 +1097,21 @@ are not available if the main thread has already terminated
.\" Added in 2.6.9
.\" CONFIG_SCHEDSTATS
.TP
+.IR /proc/[pid]/setgroups " (since Linux 3.19-rc1)"
+This file reports
+.BR allow
+if the setgroups system call is allowed in the current user namespace.
+This file reports
+.BR deny
+if the setgroups system call is not allowed in the current user namespace.
30 more quoted lines
Okay -- Iadded that point.
quoted
quoted
A privileged process (one with the CAP_SYS_ADMIN capa‐
bility in the namespace) may write either of the strings
"allow" or "deny" to this file before writing a group ID
mapping for this user namespace to the file
/proc/[pid]/gid_map. Writing the string "deny" prevents
any process in the user namespace from employing set‐
groups(2).
Or more succintly. You are allowed to write to /proc/[pid]/setgroups
when calling setgroups is not allowed because gid_map is unset. This
ensures we do not have any transitions from a state where setgroups
is allowed to a state where setgroups is denied. There are only
transitions from setgroups not-allowed to setgroups allowed.
And I've worked in the above point, rewording a bit along the way.
So, how does the following look (only the first two paragraphs have
changed)?
/proc/[pid]/setgroups (since Linux 3.19)
This file displays the string "allow" if processes in
the user namespace that contains the process pid are
permitted to employ the setgroups(2) system call, and
"deny" if setgroups(2) is not permitted in that user
namespace. (Note, however, that calls to setgroups(2)
are also not permitted if /proc/[pid]/gid_map has not
yet been set.)
A privileged process (one with the CAP_SYS_ADMIN capa‐
bility in the namespace) may write either of the strings
"allow" or "deny" to this file before writing a group ID
mapping for this user namespace to the file
/proc/[pid]/gid_map. Writing the string "deny" prevents
any process in the user namespace from employing set‐
groups(2). In other words, it is permitted to write to
/proc/[pid]/setgroups so long as calling setgroups(2) is
not allowed because /proc/[pid]gid_map has not been set.
This ensures that a process cannot transition from a
state where setgroups(2) is allowed to a state where
setgroups(2) is denied; a process can only trabsition
from setgroups(2) being disallowed to setgroups(2) being
allowed.
The default value of this file in the initial user
namespace is "allow".
Once /proc/[pid]/gid_map has been written to (which has
the effect of enabling setgroups(2) in the user names‐
pace), it is no longer possible to deny setgroups(2) by
writing to /proc/[pid]/setgroups.
A child user namespace inherits the /proc/[pid]/gid_map
setting from its parent.
20 more lines