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/