On Fri, Mar 23, 2018 at 06:13:15AM -0400, Andrew Cann wrote:
> Hello,
>
> The folowing sycall is failing when called on a Travis-CI build machine.
>
> clone(..,
> CLONE_FILES |
> CLONE_IO |
> CLONE_SIGHAND |
> CLONE_VM |
> CLONE_SYSVSEM |
> CLONE_NEWNET |
> CLONE_NEWUTS |
> CLONE_NEWUSER,
> ..
> );
>
> This works when I run it on my machine, but inside the Docker container that
> Travis creates it fails with EPERM. Can anyone suggest why this might be
> happening? The clone(2) manpage lists possible reasons:
>
>
> EPERM CLONE_NEWCGROUP, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS,
> CLONE_NEWPID,
> or CLONE_NEWUTS was specified by an unprivileged process (process
> without CAP_SYS_ADMIN).
>
> This shouldn't apply since I'm using CLONE_NEWUSER
>
>
> EPERM CLONE_PID was specified by a process other than process 0. (This error
> occurs only on Linux 2.5.15 and earlier.)
>
> Doesn't apply.
>
>
> EPERM CLONE_NEWUSER was specified in flags, but either the effective user ID
> or the effective group ID of the caller does not have a mapping in the
> parent namespace (see user_namespaces(7)).
>
> Again, this shouldn't apply. The process creating the namespace has a valid
> (not-nobody) uid and gid.
>
>
> EPERM (since Linux 3.9) CLONE_NEWUSER was specified in flags and the caller
> is in a chroot environment (i.e., the caller's root directory does not
> match the root directory of the mount namespace in which it resides).
>
> Possibly this one? The docker container shouldn't be aware that it's running
> in
> a chroot though. Calling mount inside the container lists:
>
> overlay on / type overlay (rw,relatime,...)
>
> Which indicates that it's living inside its own mount namespace with its own
> root directory.
>
> So I'm confused. Does anyone have any suggestions for why else this might be
> failing or thngs I could try to debug it? Is there a way to get more than just
> an eror code out of linux? Are there reasons for giving that error code that
> aren't listed in the man page?
Well, the Docker container might have dropped CAP_SYS_ADMIN at which
point you're not allowed to use any of the CLONE_* flags. Docker does
this as a security measure since they still default to running
privileged containers which are inherently unsafe.
Another possibility is that you're running a distro as host that does
not enable CLONE_NEWUSER by default. This can e.g. be the case with
CentOS based distros.
Christian
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
