Docker is a hot topic in the Linux world at the moment and I decided to try out the new trusted build process. Long story short, you put your Dockerfile along with any additional content into your GitHub repository, link your GitHub account with Docker, and then fire off a build. The Docker index labels it as “trusted” since it was build from source files in your repository.
I set off to build a Dockerfile to provision a container that would run all of the icanhazip services. Getting httpd running was a little tricky, but I soon had a working Dockerfile that built and ran successfully on Fedora 20.
The trusted build process kicked off without much fuss and I found myself waiting for a couple of hours for my job to start. I was sad to see an error after waiting so long:
Installing : httpd-2.4.7-3.fc20.x86_64 error: unpacking of archive failed on file /usr/sbin/suexec: cpio: cap_set_file
Well, that’s weird. It turns out that
cap_set_file is part of libcap that sets filesystem capabilities based on the POSIX.1e standards. You can read up on capabilities in the Linux kernel capabilities FAQ. (Special thanks to Andrew Clayton getting me pointed in the right direction there.)
Marek Goldmann ran into this problem back in September 2013 and opened a bug report. Marek proposed a change to the Docker codebase that would remove setfcap from the list of banned capabilities in the LXC template used by docker. Another workaround would be to use the
-privileged option to perform a build in privileged mode (available in docker 0.6+).
Both of those workarounds are unavailable when doing trusted builds with docker’s index. Sigh.
I fired off an email to Docker’s support staff and received a quick reply:
We are aware of this issue, and we are currently working on a fix, and we hope to have something we can start testing this week. I’m not sure when we will be able to roll out the fix, but we are hoping soon. Until then, there isn’t anything you can do to work around it. Sorry for the inconvenience.
If anything changes, we will be sure to let you know.
It wasn’t the answer I wanted but it’s good to know that the issue is being worked. In the meantime, I’ll push an untrusted build of the icanhazip Docker container up to the index for everyone to enjoy.
Stay tuned for updates.
UPDATED 2014-08-08: Per Thomas’ comment below, this has been fixed upstream.