estesp

package main

import (
	"fmt"
	"flag"
	"regexp"
)

var (
	fullID = regexp.MustCompile(`^[0-9a-fA-F]{64}$`)

estesp

The new generic distributed content manifest format (schema version 2) [see distribution/distribution#62] is approaching final approval, and while some discussion has happened in-line, it seems reasonable to break out the various pieces that would be required to implement a multi-arch Docker image solution on top of the flexible manifest format being proposed.

As a starting point it is useful to discuss what the intended use case is for multi-architecture images in the Docker platform. The following requirements summarize the expected capabilities of the engine + registry + storage/retrieval format that is implemented.

Requirements

• A specific repository name:tag manifest will need to contain the proper information for access/retrieval of multiple architectures
  • For example docker pull ubuntu:15.04 should have the capability on a POWER system to pull the POWER-specific image layers which comprise an Ubuntu 15.04 image
• Not every name:tag manifests will have information for

estesp

Keybase proof

I hereby claim:

• I am estesp on github.
• I am estesp (https://keybase.io/estesp) on keybase.
• I have a public key whose fingerprint is 27F3 EA26 8A97 867E AF0B D05C 0F38 6284 C03A 1162

To claim this, I am signing this object:

estesp

package main

import (
	"fmt"
	"net"
	"os"
)

func main() {
	addrs, err := net.LookupIP(os.Args[1])

estesp

Experimental user namespace support

Linux kernel user namespace support provides additional security by enabling a process--and therefore a container--to have a unique range of user and group IDs which are outside the traditional user and group range utilized by the host system. Potentially the most important security improvement is that, by default, container processes running as the root user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged uid on the host.

estesp

overlayfs copy-up without userns

Setup: create proper directories, with a pre-existing dir (called dir) in lower, and then mount as overlay fs:

$ mkdir upper lower work merged upper lower/dir
$ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged

You can now create files in the merged/dir to force a copy up of lower/dir to upper/dir:

estesp

Sampled from a 1/12/2016 run of standard Linux x64 engine janky run.

Total time of these 25 tests adds up to 663.8 seconds

These 25 make up 2.2% of total tests, but ~29% of total test runtime.

DockerDaemonSuite.TestDaemonNoSpaceleftOnDeviceError            107.143s
DockerTrustSuite.TestTrustedPushWithFailingServer               95.405s
DockerSuite.TestRunSeccompDefaultProfile                        81.711s

estesp

Image: gcr.io/google_containers/skydns:2015-10-13-8c72f8c

• Packages an exploded tarball as one of the layers: skydns_sources.tar.gz
• This tarball seems to have come from a filesystem where high uids were in use:

/skydns_sources.tar.gz # ls -al
total 12
drwxr-xr-x    3 root     root          4096 Oct 13 20:25 .
drwxr-xr-x 25 root root 4096 Apr 6 18:42 ..

estesp

The Problem

See Docker issue #24834 for the more complete background. The short story is that if lxcfs is installed (which it is by default in Ubuntu 16.04) and you attempt to use the Docker daemon with user namespaces enabled, most likely you will end up with a confusing "container command could not be invoked error" like the one here:

# docker run --rm busybox date
docker: Error response from daemon: Container command 'date' could not be invoked..

estesp

package main

import (
	"bytes"
	"context"
	"fmt"
	"os"
	"strconv"
	"strings"
	"sync"