Hi, I am investigating https://bugzilla.redhat.com/show_bug.cgi?id=1336750 and honestly I'm not sure what is the right solution.
Right now we use unshare() for CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWIPC.
I can detect if mock is running inside of container and then skip those unshare. But... What if I am running there some application *and* mock. In the same container. That can be risky. However we can just document it and let the user shoot into its own leg.
Or we can just document that you need to gave the containter privileges to run unshare().
Or we can just leave it as it is and do not support run inside of container.
Any thoughts?
On Fri, Sep 30, 2016 at 03:15:59PM +0200, Miroslav Suchý wrote:
Hi, I am investigating https://bugzilla.redhat.com/show_bug.cgi?id=1336750 and honestly I'm not sure what is the right solution.
Right now we use unshare() for CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWIPC.
I can detect if mock is running inside of container and then skip those unshare. But... What if I am running there some application *and* mock. In the same container. That can be risky. However we can just document it and let the user shoot into its own leg.
Is there some example of application that might happen to run next to mock? Running multiple applications in container is typically not trivial, so user might make an extra effort to achieve that setup.
Can't just just check that you are pid 1 in the container and be happy with that, if you want some safeguards?
On Fri, Sep 30, 2016 at 9:35 AM, Jan Pazdziora jpazdziora@redhat.com wrote:
On Fri, Sep 30, 2016 at 03:15:59PM +0200, Miroslav Suchý wrote:
Hi, I am investigating https://bugzilla.redhat.com/show_bug.cgi?id=1336750 and honestly I'm not sure what is the right solution.
Right now we use unshare() for CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWIPC.
I can detect if mock is running inside of container and then skip those unshare. But... What if I am running there some application *and* mock. In the same container. That can be risky. However we can just document it and let the user shoot into its own leg.
Is there some example of application that might happen to run next to mock? Running multiple applications in container is typically not trivial, so user might make an extra effort to achieve that setup.
Can't just just check that you are pid 1 in the container and be happy with that, if you want some safeguards?
The main case I could see wanting to run mock inside of Docker is for CI systems. One of the more popular ones is Travis CI, and the only way to get a decent environment to run mock in is with a Docker container. So I would expect mock to be run alongside other things in a CI context.
Likewise, I see this being quite valuable for people like myself using GitLab CI for continually testing specs against multiple distributions. I can set the CI environment to pull "fedora:latest", but I want to run mock builds against multiple targets (Fedora, EPEL, Mageia, etc.) and I'd like to verify it builds successfully in all of those cases. Docker runners are all I have in GitLab CI on GitLab.com.
So I would love to see this work!
Dne 30.9.2016 v 15:35 Jan Pazdziora napsal(a):
Is there some example of application that might happen to run next to mock? Running multiple applications in container is typically not trivial, so user might make an extra effort to achieve that setup.
I have no idea. People are weird sometimes. I can imagine something like httpd in container (with some content used in production), and something which runs Mock in that same container.
Can't just just check that you are pid 1 in the container and be happy with that, if you want some safeguards?
Sounds good.
What I have so far is: https://github.com/xsuchy/mock-1/commit/4a89b6fe70af5777ca5e8e0a795bd89a6057...
I can add there that pid 1 check.
On Friday, September 30, 2016 4:28:08 PM CDT Miroslav Suchý wrote:
Dne 30.9.2016 v 15:35 Jan Pazdziora napsal(a):
Is there some example of application that might happen to run next to mock? Running multiple applications in container is typically not trivial, so user might make an extra effort to achieve that setup.
I have no idea. People are weird sometimes. I can imagine something like httpd in container (with some content used in production), and something which runs Mock in that same container.
Can't just just check that you are pid 1 in the container and be happy with that, if you want some safeguards?
Sounds good.
What I have so far is: https://github.com/xsuchy/mock-1/commit/4a89b6fe70af5777ca5e8e0a795bd89a6057 6bc6
I can add there that pid 1 check.
I could see people running koji in a container as part of a development setup, which could end up running multiple mocks next to each other in the same container controlled by kojid
Dennis
On 9/30/16 7:28 AM, Miroslav Suchý wrote:
Dne 30.9.2016 v 15:35 Jan Pazdziora napsal(a):
Is there some example of application that might happen to run next to mock? Running multiple applications in container is typically not trivial, so user might make an extra effort to achieve that setup.
I have no idea. People are weird sometimes. I can imagine something like httpd in container (with some content used in production), and something which runs Mock in that same container.
Can't just just check that you are pid 1 in the container and be happy with that, if you want some safeguards?
Sounds good.
What I have so far is: https://github.com/xsuchy/mock-1/commit/4a89b6fe70af5777ca5e8e0a795bd89a6057...
I can add there that pid 1 check.
There are lots of reasons you could be running in a container and not be pid 1. You probably shouldn't check for that explicitly.
Dne 30.9.2016 v 15:15 Miroslav Suchý napsal(a):
Hi, I am investigating https://bugzilla.redhat.com/show_bug.cgi?id=1336750 and honestly I'm not sure what is the right solution.
Right now we use unshare() for CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWIPC.
I can detect if mock is running inside of container and then skip those unshare. But... What if I am running there some application *and* mock. In the same container. That can be risky. However we can just document it and let the user shoot into its own leg.
Or we can just document that you need to gave the containter privileges to run unshare().
Or we can just leave it as it is and do not support run inside of container.
Any thoughts?
So, the unshare()-skipping is working. But I got stuck on /bin/mount -n -t proc proc /var/lib/mock/fedora-24-x86_64/root/proc This fails in unprivileged containers. And I cannot skip it, because lots of RPMs will miss it.
The only way is to run docker with --cap-add=SYS_ADMIN. However according to http://lwn.net/Articles/486306/ this is very similar to running privileged container, which is very similar to running that code without container as root.
Any thoughts?
On Mon, Oct 10, 2016 at 05:44:17PM +0200, Miroslav Suchý wrote:
So, the unshare()-skipping is working. But I got stuck on /bin/mount -n -t proc proc /var/lib/mock/fedora-24-x86_64/root/proc This fails in unprivileged containers. And I cannot skip it, because lots of RPMs will miss it.
Wouldn't
ln -s /proc /var/lib/mock/fedora-24-x86_64/root/proc
work?
Dne 14.10.2016 v 15:14 Jan Pazdziora napsal(a):
Wouldn't
ln -s /proc /var/lib/mock/fedora-24-x86_64/root/proc
work?
No, sir.
ln -s /proc /var/lib/mock/fedora-24-x86_64/root/proc
Will create in chroot:
<mock-chroot> sh-4.3# ls -ld /proc lrwxrwxrwx. 1 root mockbuild 5 Oct 18 09:34 /proc -> /proc
which will yield: ls: cannot access '/proc/': Too many levels of symbolic links
buildsys@lists.fedoraproject.org
-
Dennis Gilmore -
Jan Pazdziora -
Mike Bonnet -
Miroslav Suchý -
Neal Gompa