unshare.2: Same EINVAL errors as for clone(2) can also occur with unshare(2)

The EINVAL errors that can occur for clone(2) when it is called
with various CLONE_NEW* flags and the kernel was not configured
with support for the corresponding namespace can also occur for
unshare(2).  (As far as I can see, these errors don't occur for
either clone(2) or unshare(2) when it comes to CLONE_NEWNS and
CLONE_NEWCGROUP.)

Reported-by: Shawn Landden <shawn@git.icu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2018-07-28 20:44:56 +02:00
parent 231d0bbe7e
commit 1f1c28e0a9
1 changed files with 42 additions and 0 deletions

View File

@ -288,6 +288,48 @@ was specified in
.IR flags ,
and the caller is multithreaded.
.TP
.B EINVAL
.BR CLONE_NEWIPC
was specified in
.IR flags ,
but the kernel was not configured with the
.B CONFIG_SYSVIPC
and
.BR CONFIG_IPC_NS
options.
.TP
.B EINVAL
.BR CLONE_NEWNET
was specified in
.IR flags ,
but the kernel was not configured with the
.B CONFIG_NET_NS
option.
.TP
.B EINVAL
.BR CLONE_NEWPID
was specified in
.IR flags ,
but the kernel was not configured with the
.B CONFIG_PID_NS
option.
.TP
.B EINVAL
.BR CLONE_NEWUSER
was specified in
.IR flags ,
but the kernel was not configured with the
.B CONFIG_USER_NS
option.
.TP
.B EINVAL
.BR CLONE_NEWUTS
was specified in
.IR flags ,
but the kernel was not configured with the
.B CONFIG_UTS_NS
option.
.TP
.B ENOMEM
Cannot allocate sufficient memory to copy parts of caller's
context that need to be unshared.