Quoting mail with Eric Biederman:
>>> So, by the way, I added this sentence to the page:
>>>
>>> In order to write to the /proc/[pid]/uid_map
>>> (/proc/[pid]/gid_map) file, a process must have the
>>> CAP_SETUID (CAP_SETGID) capability in the user namespace
>>> of the process pid.
>>>
>>> Is that correct?
>>
>> Yes.
>>
>>> But, there appear to be more rules than this governing whether a
>>> process can write to the file (i.e., various other -EPERM cases). What
>>> are the rules?
>>
>> In general you must also have CAP_SETUID (CAP_SETGID) in the parent user
>> namespace as well. The one exception to that is if you are mapping
>> your current uid and gid.
>
> Can you clarify what you mean by "mapping your own UID and GID" please
> (i.e., who is "you" in that sentence).
At the time of clone() or unshare() that creates a new user namespace,
the kuid and the kgid of the process does not change.
setuid and setgid fail before any mappings are set up.
Therefore the caller is allowed to map any single uid to the uid of the
caller in the parent user namespace. Likewise the caller is allowed to
map any single gid to the gid of the caller in the parent user
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The pieces on uid_map, gd_map and CLONE_NEWUSER were
originally drafted (in other pages) by Eric Biederman.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk