Bug 1336750

Summary:	it's not easy to run mock in an unprivileged docker container
Product:	[Fedora] Fedora	Reporter:	Tomas Tomecek <ttomecek>
Component:	mock	Assignee:	Miroslav Suchý <msuchy>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	25	CC:	allanlewis99, carl, dwalsh, fche, imcleod, jdisnard, mebrown, msimacek, msuchy, nalin, philwyett.hemisphere, praiskup, sagarun, vbatts, walters, williams
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	mock-1.3.2-1.fc25	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-22 04:01:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tomas Tomecek 2016-05-17 11:51:19 UTC

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.

Comment 1 Miroslav Suchý 2016-05-17 14:35:12 UTC

The first issue is basically duplicate of bug 1246810.

So lets focus only on item 2 in this report.

Comment 2 Jan Kurik 2016-07-26 05:12:26 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 3 Miroslav Suchý 2016-10-11 08:41:51 UTC

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.

Comment 4 Fedora Update System 2016-10-19 08:29:50 UTC

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

Comment 5 Tomas Tomecek 2016-10-19 10:43:40 UTC

Can confirm the patch fixes the original issue.

Comment 6 Fedora Update System 2016-10-22 04:01:14 UTC

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.

Comment 7 Phil Wyett 2016-11-02 05:13:43 UTC

Is this fix scheduled to be a patch for RHEL 7?

Comment 8 Frank Ch. Eigler 2017-06-07 22:14:36 UTC

(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)?

Comment 9 Colin Walters 2017-06-08 12:57:36 UTC

@frank: User namespaces address that - they allow recursive containerization.

Comment 10 Frank Ch. Eigler 2017-06-08 13:04:12 UTC

(In reply to Colin Walters from comment #9)
> @frank: User namespaces address that - they allow recursive containerization.

Does that trump the sysadmin capabilities?

Comment 11 Daniel Walsh 2017-06-08 13:58:27 UTC

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?

Comment 12 Miroslav Suchý 2017-06-12 21:45:05 UTC

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.

Comment 13 Daniel Walsh 2017-06-13 12:49:27 UTC

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