From outside a PID namespace, only the SIGKILL and SIGSTOP
signals can be sent to the init process.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If the PID namespace init process has terminated, then
setns() on a previously opened /proc/PID/ns/pid file
will succeed, but the subsequent fork() will fail with
ENOMEM.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
PIDs passed via UNIX domain sockets are translated according to
the receiving process's namespace.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The text probably doesn't help the readers understanding much,
and it's not quite accurate in the case of PID namespaces.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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