create-runtime-bundle: generates incorrect Linux config

[cyphar]

Currently if you take a random Docker image's config file (then translate it to an OCI one using skopeo) you'll get a config.json which looks like this:

{
  "ociVersion": "1.0.0-rc2",
  "platform": {
    "os": "linux",
    "arch": "amd64"
  },
  "process": {
    "terminal": true,
    "user": {
      "uid": 0,
      "gid": 0
    },
    "args": [
      "sh"
    ],
    "env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "cwd": "/"
  },
  "root": {
    "path": "rootfs"
  },
  "hooks": {},
  "linux": {
    "resources": {
      "memory": {
        "limit": 0,
        "reservation": 0,
        "swap": 0
      },
      "cpu": {
        "shares": 0
      }
    }
  }
}

This is wrong. On Linux you have to include the "namespaces": [ { "type": "mount" } ] at the very least in order for it to even be possible for you to start inside a container (otherwise your container is running the host context -- not very useful). Preferably we should also add the PID namespace.

In addition, we have to add the default set of mounts mandated by opencontainers/runtime-spec#164. Namely we have to add /proc, /sys and /dev (runC will handle everything else for us).

[wking]

On Sat, Nov 05, 2016 at 08:50:09PM -0700, Aleksa Sarai wrote:

This is wrong. On Linux you have to include the "namespaces": [ { "type": "mount" } ] at the very least in order for it to even be possible for you to start inside a container.

I agree that the spec gets very confusing for folks who don't specify a mount namespace, but I don't actually see wording in the spec requiring you to specify one 1. Although the no-tweaking rule 2 probably means you'd have to specify it if you put anything in the root ‘mounts’. However, I think the right approach to that is to clarify the config for the host-mount-namespace case (e.g. with 3).

However, that is all fairly orthogonal to the OCI image tooling, where I'd rather avoid this problem by using the runtime-spec config instead of the current image-spec-defined runtime configuration (discussion in #87). This keeps on being a solution to lots of problems, and it would be good to hear back from maintainers on whether this approach has any legs, or if we need to continue patching around the current missmatch one issue at a time. My suggestion is to re-open #87 4 and reach a consensus about whether we want to keep the current image-spec-defined runtime config on life support, or give it a merciful death and move on with the runtime-spec configuration.

In addition, we have to add the default set of mounts mandated by opencontainers/runtime-spec#164. Namely we have to add /proc, /sys and /dev (runC will handle everything else for us).

See opencontainers/runtime-tools#24 patching runtime validation to work around runC's current implementation, but my reading of the spec 5 is that the runtime is responsible for ensuring these are present when platform.os == "linux" regardless of the rest of the spec.

 Subject: Dropping the rootfs requirement and restoring arbitrary bundle
   content
 Date: Wed, 26 Aug 2015 12:54:47 -0700
 Message-ID: <[email protected]>

[cyphar]

Whether we should eventually drop it is an entirely separate discussion. What's important right now is that we generate config.json payloads that are actually useful. cyphar/umoci#13 has my opinion on what a nice way of solving this would be (it uses oci-runtime-tools generate's library).

[wking]

On Sat, Nov 05, 2016 at 09:26:17PM -0700, Aleksa Sarai wrote:

What's important right now is that we generate config.json payloads that are actually useful. cyphar/umoci#13 has my opinion on what a nice way of solving this would be (it uses oci-runtime-tools generate's library).

This sounds good to me. The more runtime stuff we can punt to runtime projects, the happier I'll be.

[resouer]

@crazykev pay attention to this issue for ocid work please

[cyphar]

@crazykev pay attention to this issue forocid work please

I'm working on an unpacking library for umoci, because the one in this repo isn't really up-to-snuff (IMO). I will work on getting that library merged here, but in the meantime (that will almost certainly take forever) you can keep your eye on this repo1.

Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/