buildah: Error during unshare(CLONE_NEWUSER): Operation not permitted
Description
I cannot run buildah bud
Steps to reproduce the issue:
docker run --rm -it ubuntu
Within the docker container I run the following:
https://github.com/containers/buildah/blob/master/install.md#ubuntu
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# buildah bud -f Dockerfile .
Error during unshare(CLONE_NEWUSER): Operation not permitted
ERRO[0000] error parsing PID "": strconv.Atoi: parsing "": invalid syntax
ERRO[0000] (unable to determine exit status)
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# buildah --version
buildah version 1.10.1 (image-spec 1.0.1, runtime-spec 1.0.1-dev)
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# cat /proc/sys/user/max_user_names
paces
62901
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# cat "/proc/sys/kernel/unprivileged_userns_clone"
1
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test#
Describe the results you expected:
I expected everything to work our and build the OCI image.
Output of rpm -q buildah or apt list buildah:
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# apt list buildah
Listing... Done
buildah/bionic,now 1.10.1-1~ubuntu18.04~ppa1 amd64 [installed]
Output of buildah version:
buildah version 1.10.1 (image-spec 1.0.1, runtime-spec 1.0.1-dev)
Output of podman version if reporting a podman build issue:
not installed
Output of cat /etc/*release:
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
Output of uname -a:
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# uname -a
Linux dbdb5cd66273 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Output of cat /etc/containers/storage.conf:
(( default one ))
root@dbdb5cd66273:/rootfs/ci/dockerfiles/test# cat /etc/containers/storage.conf
# storage.conf is the configuration file for all tools
# that share the containers/storage libraries
# See man 5 containers-storage.conf for more information
# The "container storage" table contains all of the server options.
[storage]
# Default Storage Driver
driver = "overlay"
# Temporary storage location
runroot = "/var/run/containers/storage"
# Primary read-write location of container storage
graphroot = "/var/lib/containers/storage"
[storage.options]
# AdditionalImageStores is used to pass paths to additional read-only image stores
# Must be comma separated list.
additionalimagestores = [
]
# Size is used to set a maximum size of the container image. Only supported by
# certain container storage drivers (currently overlay, zfs, vfs, btrfs)
size = ""
# OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
override_kernel_check = "true"
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 39 (21 by maintainers)
Commits related to this issue
- Use podman's seccomp.json when starting containers in CI https://github.com/containers/buildah/issues/1901 [noissue] — committed to dkliban/pulp_container by dkliban 4 years ago
- Use podman's seccomp.json when starting containers in CI https://github.com/containers/buildah/issues/1901 [noissue] — committed to dkliban/pulp_container by dkliban 4 years ago
- Run the containers with an 'unconstrained' security profile. https://github.com/containers/buildah/issues/1901 [noissue] — committed to dkliban/pulp_container by dkliban 4 years ago
- Run the containers with an 'unconfined' security profile. https://github.com/containers/buildah/issues/1901 [noissue] — committed to dkliban/pulp_container by dkliban 4 years ago
- Run the containers with an 'unconfined' security profile. https://github.com/containers/buildah/issues/1901 [noissue] — committed to dkliban/pulp_container by dkliban 4 years ago
- Run the containers with an 'unconfined' security profile. https://github.com/containers/buildah/issues/1901 [noissue] — committed to mdellweg/pulp_container by dkliban 4 years ago
- Run the containers with an 'unconfined' security profile. https://github.com/containers/buildah/issues/1901 [noissue] — committed to mdellweg/pulp_container by dkliban 4 years ago
- Run the containers with an 'unconfined' security profile. https://github.com/containers/buildah/issues/1901 [noissue] — committed to dkliban/pulp_container by dkliban 4 years ago
- Use buildah chroot isolation while building This seems to be the recommended way to run buildah when already inside a container, see https://github.com/containers/buildah/issues/1901#issuecomment-638... — committed to VannTen/meteor-operator by VannTen 2 years ago
- Use buildah chroot isolation while building This seems to be the recommended way to run buildah when already inside a container, see https://github.com/containers/buildah/issues/1901#issuecomment-638... — committed to VannTen/meteor-operator by VannTen 2 years ago
- Use buildah chroot isolation while building This seems to be the recommended way to run buildah when already inside a container, see https://github.com/containers/buildah/issues/1901#issuecomment-638... — committed to VannTen/meteor-operator by VannTen 2 years ago
Still encountering this issue on
quay.io/containers/buildah:v1.28doingThe container is run inside a Gitlab CI Pipeline
Could you try this with podman? Also could you try docker run --security-opt seccomp=/usr/share/containers/seccomp.json --rm -it -v $(pwd):/rootfs quay.io/buildah/stable
I think Docker might be blocking the unshare syscall.
Sorry but when building a image from inside a Jenkins container agent it is useful. Since dockerd is deprecated in Kubernetes we need an alternative; Is it possible with Buildah or do we need to find something else ?
@giuseppe am I right that people need to “unblock unshare” anyway to build containers in containers with
buildah? In that so case the decision just makes a false claim of security. Likebuildahis placing blame on users/developers without providing any secure alternative.I also came here from GitLab, because I saw
buildahas alternative to Docker in Docker. I thought it is just a a simple user space that takes files and packs them. It is very frustrating to spend time in yet another layer of problems with no result.The goal is not to have a docker socket available in a Container but to build a container image inside a CI agent running in K8S
That would require a privileged pod though.
@abitrolly I had the same aspirations to use buildah - since we’re 100% on podman anyway. I’ve since switched to kaniko which was a breeze to get going
The comment should have been more specific. Basically locking down a process within a container with additional duplicative lock down is not worth it. So if I have dropped caps, and running with SELinux lock down and seccomp rules locked down, then don’t attempt to do them again. If the container engines attempt to, they will be blocked, because of the existing container lockdown and your container engine will fail.
It is possible to run buildah and podman within a container. The issue is how much security you lock said container down with.
Running docker within a container has the same issues. It requires a --priivleged container or a container with a leaked docker.socket from the host into the container, which is arguably less secure then just running --privileged.
So docker seccomp.json file blocking unshare is the issue, and should be changed, or as I reccoment use podman/CRI-O for running these containers. You can run docker with Podman /usr/share/containers/seccomp.json file.
@giuseppe Why, what do we need this for? I guess we are still bind mounting the /proc and /sys into the chroot.
Not sure if this is the case on Ubuntu, but on Debian the kernel itself disables the unsharing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808915.
I had to manually allow unprivileged users to unshare, get Docker to use Podman’s seccomp profile, and then Buildah ran in the container. Using
--isolation=chroothad no effect, unfortunately.It doesn’t seem to help at all:
Also it appears to be default isolation as well in the container.