This bug covers two issues: 1) RuntimeError: mock will not run from the root account (needs an unprivileged uid so it can drop privs) Usually when you start a docker container, you have root access inside (with user namespaces or not). It would be convenient if mock was able to run under root account. Current solution is to create a new user and run mock with this user, dockerfile snippet: RUN useradd -o -u 1000 -G mock user USER user 2) ERROR: Namespace unshare failed. docker is already handling namespaces, I don't want mock to do the same. Current workaround is to give the container needed capabilities so it's able to call unshare correctly.
The first issue is basically duplicate of bug 1246810. So lets focus only on item 2 in this report.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Fixed in commit: * b34a4e7 (HEAD -> devel) skip unshare() if running inside of Docker [RHBZ#1336750] However because we need to mount procfs in chroot, you have to pass --cap-add=SYS_ADMIN to docker.
mock-1.3.2-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-07f2f5e2c9
Can confirm the patch fixes the original issue.
mock-1.3.2-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Is this fix scheduled to be a patch for RHEL 7?
(In reply to Miroslav Suchý from comment #3) > However because we need to mount procfs in chroot, you have to pass > --cap-add=SYS_ADMIN to docker. If it needs SYS_ADMIN capabilities, can we really construe it to be an unprivileged docker container? Is there any followup work envisioned to make that purely-unprivileged case work (such as in an openshift environment)?
@frank: User namespaces address that - they allow recursive containerization.
(In reply to Colin Walters from comment #9) > @frank: User namespaces address that - they allow recursive containerization. Does that trump the sysadmin capabilities?
You would get a usernamespaces SYS_ADMIN rather then true SYS_ADMIN. It may or may not work, depending on why the container needs SYS_ADMIN. Certain Mount operations are still blocked inside of a User Namespaced container. Can mock be rewritten to not need to use the chroot? Since it is already in a container?
The plan is to use container (for now systemd-nspawn) instead of chroot. So having mock inside of Docker is like having container which has been started by Mock, which is inside of container. Which is afaik only possible if the first docker is privileged. And mock without chroot? That is basicaly rpmbuild. If we do not use chroot or container we will loose main feature of Mock: that you have only installed those packages which you specified in BuildRequires and nothing else.
I don't think you need to do this inside of docker, actually I would recommend against it. I would think integration with runc would be a much better solution, since you don't need anything special installed on the host, no daemons required. I am just attempting to think about this differently then traditional Mock. Two features we need in mock is to install an environment from scratch and then run commands inside of the container. Might even want to look at Buildah to see if this could fit the build. ctr=$(buildah from scratch) mp=$(buildah mount $ctr) dnf --installroot $mp DEPENDENCIESFORPACKAGE cp SRPM $mp/tmp buildah run $ctr rpmbuild -ba