2017-03-03 03:00:31 +08:00
# <a name="containerConfigurationFile" />Container Configuration file
2015-06-25 08:15:48 +08:00
2017-05-11 11:02:17 +08:00
This configuration file contains metadata necessary to implement [standard operations ](runtime.md#operations ) against the container.
2017-03-17 06:26:26 +08:00
This includes the process to run, environment variables to inject, sandboxing features to use, etc.
2016-07-19 11:37:23 +08:00
The canonical schema is defined in this document, but there is a JSON Schema in [`schema/config-schema.json` ](schema/config-schema.json ) and Go bindings in [`specs-go/config.go` ](specs-go/config.go ).
2016-09-15 23:26:13 +08:00
[Platform ](spec.md#platforms )-specific configuration schema are defined in the [platform-specific documents ](#platform-specific-configuration ) linked below.
For properties that are only defined for some [platforms ](spec.md#platforms ), the Go property has a `platform` tag listing those protocols (e.g. `platform:"linux,solaris"` ).
2015-06-25 08:15:48 +08:00
2017-01-31 04:11:34 +08:00
Below is a detailed description of each field defined in the configuration format and valid values are specified.
Platform-specific fields are identified as such.
For all platform-specific configuration values, the scope defined below in the [Platform-specific configuration ](#platform-specific-configuration ) section applies.
2015-06-25 08:15:48 +08:00
2017-03-03 03:00:31 +08:00
## <a name="configSpecificationVersion" />Specification version
2015-06-25 08:15:48 +08:00
2017-02-10 04:32:39 +08:00
* **`ociVersion`** (string, REQUIRED) MUST be in [SemVer v2.0.0][semver-v2.0.0] format and specifies the version of the Open Container Runtime Specification with which the bundle complies.
2016-08-03 14:32:43 +08:00
The Open Container Runtime Specification follows semantic versioning and retains forward and backward compatibility within major versions.
config: Clarify ociVersion covering the configuration <-> runtime API
There are other APIs described in this specification (e.g. the state
JSON format, and the in-flight command-line API [1]), but this string
covers the configuration file and referenced objects (e.g. the
filesystem at root.path). As additional, backwards compatible
features are added to the spec (leading to 1.1, 1.2, etc. releases)
and supported by runtimes, those runtimes will *still* stupport 1.0
configs. Once a 2.0 spec is cut, runtimes that only support 2.0 (and
nothing in the 1.0 line) will no longer support the 1.0 config.
My preferred approach here would be to use JSON-LD [2,3,4] to
explicitly document the intended semantics for each field, which would
allow us to drop the config-wide version and version each field
independently. That would mean a breaking change on a particular
field would only break compatibility for folks who were using that
field. Unfortunately, I haven't had much luck pushing the consensus
in that direction.
This commit does not add wording about how the runtime and other
consumers should handle an incompatible version. We can address that
once the command-line API lands.
[1]: https://github.com/opencontainers/runtime-spec/pull/513
[2]: https://github.com/opencontainers/runtime-spec/pull/371#issuecomment-209684002
[3]: https://github.com/opencontainers/image-spec/pull/111#discussion_r65619280
[4]: https://github.com/opencontainers/runtime-spec/pull/510#discussion_r68513241
Signed-off-by: W. Trevor King <wking@tremily.us>
2016-07-27 05:22:16 +08:00
For example, if a configuration is compliant with version 1.1 of this specification, it is compatible with all runtimes that support any 1.1 or later release of this specification, but is not compatible with a runtime that supports 1.0 and not 1.1.
2015-06-25 08:15:48 +08:00
2016-03-17 09:26:12 +08:00
### Example
2015-07-01 06:16:51 +08:00
2015-06-30 02:54:10 +08:00
```json
2016-01-14 07:10:54 +08:00
"ociVersion": "0.1.0"
2015-06-25 08:15:48 +08:00
```
2017-03-03 03:00:31 +08:00
## <a name="configRoot" />Root
2015-06-25 08:15:48 +08:00
2017-01-31 04:11:34 +08:00
**`root`** (object, REQUIRED) specifies the container's root filesystem.
2015-07-02 02:43:43 +08:00
2016-09-18 13:01:53 +08:00
* **`path`** (string, REQUIRED) Specifies the path to the root filesystem for the container.
2017-01-31 04:11:34 +08:00
The path is either an absolute path or a relative path to the bundle.
On Linux, for example, with a bundle at `/to/bundle` and a root filesystem at `/to/bundle/rootfs` , the `path` value can be either `/to/bundle/rootfs` or `rootfs` .
2016-07-22 14:06:54 +08:00
A directory MUST exist at the path declared by the field.
2017-05-13 09:27:06 +08:00
* **`readonly`** (bool, OPTIONAL) If true then the root filesystem MUST be read-only inside the container, defaults to false. On Windows, this field must be omitted or false.
2015-06-25 08:15:48 +08:00
2016-03-17 09:26:12 +08:00
### Example
2015-07-01 06:16:51 +08:00
2015-06-30 02:54:10 +08:00
```json
2015-07-01 06:16:51 +08:00
"root": {
"path": "rootfs",
"readonly": true
}
2015-06-25 08:15:48 +08:00
```
2017-03-03 03:00:31 +08:00
## <a name="configMounts" />Mounts
2015-09-02 23:42:54 +08:00
2017-03-30 02:17:32 +08:00
**`mounts`** (array of objects, OPTIONAL) specifies additional mounts beyond [`root` ](#root ).
2015-09-04 00:56:47 +08:00
The runtime MUST mount entries in the listed order.
2017-02-10 04:32:39 +08:00
For Linux, the parameters are as documented in [mount(2)][mount.2] system call man page.
For Solaris, the mount entry corresponds to the 'fs' resource in the [zonecfg(1M)][zonecfg.1m] man page.
2017-01-31 04:11:34 +08:00
2015-09-02 23:42:54 +08:00
2016-09-18 13:01:53 +08:00
* **`destination`** (string, REQUIRED) Destination of mount point: path inside container.
config: Require absolute mount destinations
'destination' has been the path inside the container since c18c283a
(Change layout of mountpoints and mounts, 2015-09-02, #136). My
personal preference is to have an explicit pivot root and allow paths
relative to the current working directory [1], but that would be a big
shift from the current OCI spec. The only way the current spec lets
you turn off the root pivot is by not setting a mount namespace at all
(and even then, it's not clear if that turns off the pivot). And the
config's root entry is required (despite my attempts to have it made
optional [2]), so it's not really clear how containers that don't set
a mount namespace are supposed to work (if they're supported at all).
You might be able to get away with something like:
When a mount namespace is not set, destination paths are relative to
the runtime's initial working directory (or relative to the
config.json, or whatever). When a mount namespace is set,
destination paths are relative to the mount namespace's root.
but with mount-namespace-less containers already so unclear, it seems
better to just require absolute destinations. If/when we get clearer
support for explicit pivot-root calls or containers that inherit the
host mount namespace (without re-joining it and losing their old
working directory), we can consider lifting the absolute-path
restriction.
[1]: https://github.com/wking/ccon/tree/v0.4.0#mount-namespace
[2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU
Date: Wed, 26 Aug 2015 12:54:47 -0700
Subject: Dropping the rootfs requirement and restoring arbitrary bundle
content
Message-ID: <20150826195447.GX21585@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2016-11-04 14:05:57 +08:00
This value MUST be an absolute path.
2017-01-31 04:11:34 +08:00
* Windows: one mount destination MUST NOT be nested within another mount (e.g., c:\\foo and c:\\foo\\bar).
2017-02-10 04:32:39 +08:00
* Solaris: corresponds to "dir" of the fs resource in [zonecfg(1M)][zonecfg.1m].
2017-02-28 02:09:22 +08:00
* **`type`** (string, OPTIONAL) The filesystem type of the filesystem to be mounted.
2017-01-31 04:11:34 +08:00
* Linux: valid *filesystemtype* supported by the kernel as listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660").
2017-05-13 11:28:44 +08:00
* Windows: this field MUST NOT be supplied.
2017-02-10 04:32:39 +08:00
* Solaris: corresponds to "type" of the fs resource in [zonecfg(1M)][zonecfg.1m].
2017-02-28 02:09:22 +08:00
* **`source`** (string, OPTIONAL) A device name, but can also be a directory name or a dummy.
2017-05-13 11:28:44 +08:00
* Windows: a local directory on the filesystem of the container host. UNC paths and mapped drives are not supported.
2017-02-10 04:32:39 +08:00
* Solaris: corresponds to "special" of the fs resource in [zonecfg(1M)][zonecfg.1m].
2016-09-18 12:59:07 +08:00
* **`options`** (list of strings, OPTIONAL) Mount options of the filesystem to be used.
2017-02-10 04:32:39 +08:00
* Linux: supported options are listed in the [mount(8)][mount.8] man page. Note both [filesystem-independent][mount.8-filesystem-independent] and [filesystem-specific][mount.8-filesystem-specific] options are listed.
* Solaris: corresponds to "options" of the fs resource in [zonecfg(1M)][zonecfg.1m].
2015-09-02 23:42:54 +08:00
2016-03-17 09:26:12 +08:00
### Example (Linux)
2015-09-02 23:42:54 +08:00
```json
"mounts": [
{
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
"destination": "/tmp",
"type": "tmpfs",
"source": "tmpfs",
"options": ["nosuid","strictatime","mode=755","size=65536k"]
2015-09-02 23:42:54 +08:00
},
{
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
"destination": "/data",
"type": "bind",
"source": "/volumes/testing",
"options": ["rbind","rw"]
2015-09-02 23:42:54 +08:00
}
]
```
2016-03-17 09:26:12 +08:00
### Example (Windows)
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
```json
"mounts": [
2017-03-17 06:48:15 +08:00
{
2017-05-13 11:28:44 +08:00
"destination": "C:\\folder-inside-container",
"source": "C:\\folder-on-host",
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
"options": []
}
]
```
2016-10-13 01:33:35 +08:00
### Example (Solaris)
```json
"mounts": [
{
"destination": "/opt/local",
"type": "lofs",
"source": "/usr/local",
"options": ["ro","nodevices"]
},
{
"destination": "/opt/sfw",
"type": "lofs",
"source": "/opt/sfw"
}
]
```
2017-03-03 03:00:31 +08:00
## <a name="configProcess" />Process
2015-06-25 08:15:48 +08:00
config: Make process optional
Since be59415 (Split create and start, 2016-04-01, #384), it's
possible for a container process to never execute user-specified code
(e.g. you can call 'create', 'kill', 'delete' without calling
'start'). For folks who expect to do that, there's no reason to
define process.args.
The only other process property required for all platforms is 'cwd',
but the runtime's idler code isn't specified in sufficient detail for
the configuration author to have an opinion about what its working
directory should be.
On Linux and Solaris, 'user' is also required for 'uid' and 'gid'. My
preferred approach here is to make those optional and define defaults
[1,2]:
If unset, the runtime will not attempt to manipulate the user ID
(e.g. not calling setuid(2) or similar).
But the maintainer consensus is that they want those to be explicitly
required properties [3,4,5]. With the current spec, one option could
be to make process optional (with the idler's working directory
unspecified) for OSes besides Linux and Solaris. On Windows, username
is optional, but that was likely accidental [6].
So an unspecified 'process' would leave process.cwd and process.user
unset. What that means for the implementation-defined container
process between 'create' and 'start' is unclear, but clarifying how
that is handled is a separate issue [7] independent of whether
'process' is optional or not.
[1]: https://github.com/opencontainers/runtime-spec/pull/417#issuecomment-216076069
[2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A
Subject: Exposing platform defaults
Date: Thu, 14 Jan 2016 15:36:26 -0800
Message-ID: <20160114233625.GN6362@odin.tremily.us>
[3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44
[4]: https://github.com/opencontainers/runtime-spec/pull/417#issuecomment-216937010
[5]: https://github.com/opencontainers/runtime-spec/pull/417#issuecomment-216937090
[6]: https://github.com/opencontainers/runtime-spec/issues/618#issuecomment-277105273
[7]: https://github.com/opencontainers/runtime-spec/pull/700
Signed-off-by: W. Trevor King <wking@tremily.us>
2017-02-28 04:19:20 +08:00
**`process`** (object, OPTIONAL) specifies the container process.
This property is REQUIRED when [`start` ](runtime.md#start ) is called.
2016-08-03 14:45:11 +08:00
2016-11-11 04:00:59 +08:00
* **`terminal`** (bool, OPTIONAL) specifies whether a terminal is attached to that process, defaults to false.
2017-01-31 04:11:34 +08:00
As an example, if set to true on Linux a pseudoterminal pair is allocated for the container process and the pseudoterminal slave is duplicated on the container process's [standard streams][stdin.3].
2017-04-07 13:35:56 +08:00
* **`consoleSize`** (object, OPTIONAL) specifies the console size in characters of the terminal if attached, containing the following properties:
2017-03-14 10:22:01 +08:00
* **`height`** (uint, REQUIRED)
* **`width`** (uint, REQUIRED)
2016-09-18 13:01:53 +08:00
* **`cwd`** (string, REQUIRED) is the working directory that will be set for the executable.
2016-07-22 14:06:54 +08:00
This value MUST be an absolute path.
2016-05-20 13:04:52 +08:00
* **`env`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001's `environ` ][ieee-1003.1-2001-xbd-c8.1].
config: Adjust process.args to cite POSIX's execvp
This punts the awkward-to-enforce "MUST be available at the given path
inside of the rootfs" to the kernel, which will do a much better job
of enforcing that constraint than runtime code or a static validator.
It also punts most of the semantics to POSIX, which does a better job
than we'll do at specifying this. The extension is necessary because
POSIX allows argv to be empty. In the DESCRIPTION:
The argument arg0 should point to a filename that is associated with
the process being started by one of the exec functions.
And in RATIONALE:
Early proposals required that the value of argc passed to main() be
"one or greater". This was driven by the same requirement in drafts
of the ISO C standard. In fact, historical implementations have
passed a value of zero when no arguments are supplied to the caller
of the exec functions. This requirement was removed from the ISO C
standard and subsequently removed from this volume of IEEE Std
1003.1-2001 as well. The wording, in particular the use of the word
should, requires a Strictly Conforming POSIX Application to pass at
least one argument to the exec function, thus guaranteeing that argc
be one or greater when invoked by such an application. In fact,
this is good practice, since many existing applications reference
argv[0] without first checking the value of argc.
But with an empty 'args' we will have no process to call (since
process lacks an explicit 'file' analog).
I chose the 2001/2004 POSIX spec for consistency with the existing
reference (which landed in 7ac41c69, config.md: reformat into a
standard style, 2015-06-30, which did not motivate it's use of an
older standard). For 2001 vs. 2004, [1] has:
Abstract: The 2004 edition incorporates Technical Corrigendum Number
1 and Technical Corrigendum 2 addressing problems discovered since
the approval of the 2001 edition. These are mainly due to resolving
integration issues raised by the merger of the Base documents.
and the text in the linked pages uses "IEEE Std 1003.1-2001" for
internal linking.
Rob Dolin had suggested "platform-appropriate" wording [2], but it
seems like Visual Studio 2015 supports execvp [3], and providing an
explicit "platform-appropriate" wiggle seems like it's adding useless
complication.
[1]: http://pubs.opengroup.org/onlinepubs/009695399/mindex.html
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-54
[3]: https://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
Signed-off-by: W. Trevor King <wking@tremily.us>
2016-05-20 13:32:56 +08:00
* **`args`** (array of strings, REQUIRED) with similar semantics to [IEEE Std 1003.1-2001 `execvp` 's *argv* ][ieee-1003.1-2001-xsh-exec].
This specification extends the IEEE standard in that at least one entry is REQUIRED, and that entry is used with the same semantics as `execvp` 's *file* .
2017-05-10 04:44:21 +08:00
* **`capabilities`** (object, OPTIONAL) is an object containing arrays that specifies the sets of capabilities for the process(es) inside the container. Valid values are platform-specific. For example, valid values for Linux are defined in the [capabilities(7)][capabilities.7] man page, such as `CAP_CHOWN` . Any value which cannot be mapped to a relevant kernel interface MUST cause an error.
2017-02-03 06:57:42 +08:00
capabilities contains the following properties:
* **`effective`** (array of strings, OPTIONAL) - the `effective` field is an array of effective capabilities that are kept for the process.
* **`bounding`** (array of strings, OPTIONAL) - the `bounding` field is an array of bounding capabilities that are kept for the process.
* **`inheritable`** (array of strings, OPTIONAL) - the `inheritable` field is an array of inheritable capabilities that are kept for the process.
* **`permitted`** (array of strings, OPTIONAL) - the `permitted` field is an array of permitted capabilities that are kept for the process.
* **`ambient`** (array of strings, OPTIONAL) - the `ambient` field is an array of ambient capabilities that are kept for the process.
2016-11-03 09:02:39 +08:00
* **`rlimits`** (array of objects, OPTIONAL) allows setting resource limits for a process inside the container.
Each entry has the following structure:
2017-02-10 04:32:39 +08:00
* **`type`** (string, REQUIRED) - the platform resource being limited, for example on Linux as defined in the [setrlimit(2)][setrlimit.2] man page.
2017-01-31 04:11:34 +08:00
* **`soft`** (uint64, REQUIRED) - the value of the limit enforced for the corresponding resource.
* **`hard`** (uint64, REQUIRED) - the ceiling for the soft limit that could be set by an unprivileged process. Only a privileged process (e.g. under Linux: one with the CAP_SYS_RESOURCE capability) can raise a hard limit.
2016-11-03 09:02:39 +08:00
If `rlimits` contains duplicated entries with same `type` , the runtime MUST error out.
2016-09-18 12:59:07 +08:00
* **`noNewPrivileges`** (bool, OPTIONAL) setting `noNewPrivileges` to true prevents the processes in the container from gaining additional privileges.
2017-02-10 04:32:39 +08:00
As an example, the ['no_new_privs'][no-new-privs] article in the kernel documentation has information on how this is achieved using a prctl system call on Linux.
2017-01-31 04:11:34 +08:00
2017-05-10 19:57:34 +08:00
For Linux-based systems the process structure supports the following process-specific fields.
2017-01-31 04:11:34 +08:00
* **`apparmorProfile`** (string, OPTIONAL) specifies the name of the AppArmor profile to be applied to processes in the container.
2017-02-10 04:32:39 +08:00
For more information about AppArmor, see [AppArmor documentation][apparmor].
2017-05-10 00:40:06 +08:00
* **`oomScoreAdj`** *(int, OPTIONAL)* adjusts the oom-killer score in `[pid]/oom_score_adj` for the container process's `[pid]` in a [proc pseudo-filesystem][procfs].
If `oomScoreAdj` is set, the runtime MUST set `oom_score_adj` to the given value.
If `oomScoreAdj` is not set, the runtime MUST NOT change the value of `oom_score_adj` .
This is a per-process setting, where as [`disableOOMKiller` ](config-linux.md#disable-out-of-memory-killer ) is scoped for a memory cgroup.
For more information on how these two settings work together, see [the memory cgroup documentation section 10. OOM Contol][cgroup-v1-memory_2].
2017-01-31 04:11:34 +08:00
* **`selinuxLabel`** (string, OPTIONAL) specifies the SELinux label to be applied to the processes in the container.
2017-02-10 04:32:39 +08:00
For more information about SELinux, see [SELinux documentation][selinux].
2016-03-03 03:40:09 +08:00
2017-03-03 03:00:31 +08:00
### <a name="configUser" />User
2016-03-17 09:17:18 +08:00
2015-07-02 00:58:39 +08:00
The user for the process is a platform-specific structure that allows specific control over which user the process runs as.
2016-03-17 09:17:18 +08:00
2017-03-03 03:00:31 +08:00
#### <a name="configLinuxAndSolarisUser" />Linux and Solaris User
2016-03-17 09:17:18 +08:00
2016-04-26 11:03:09 +08:00
For Linux and Solaris based systems the user structure has the following fields:
2015-07-01 06:58:24 +08:00
2017-02-10 04:32:39 +08:00
* **`uid`** (int, REQUIRED) specifies the user ID in the [container namespace ](glossary.md#container-namespace ).
* **`gid`** (int, REQUIRED) specifies the group ID in the [container namespace ](glossary.md#container-namespace ).
* **`additionalGids`** (array of ints, OPTIONAL) specifies additional group IDs (in the [container namespace ](glossary.md#container-namespace ) to be added to the process.
2015-07-01 06:58:24 +08:00
2016-03-17 09:17:18 +08:00
_Note: symbolic name for uid and gid, such as uname and gname respectively, are left to upper levels to derive (i.e. `/etc/passwd` parsing, NSS, etc)_
2016-03-17 09:26:12 +08:00
### Example (Linux)
2015-07-01 06:16:51 +08:00
2015-06-30 02:54:10 +08:00
```json
2015-07-01 06:16:51 +08:00
"process": {
"terminal": true,
2016-09-15 04:12:21 +08:00
"consoleSize": {
"height": 25,
"width": 80
},
2015-07-01 06:58:24 +08:00
"user": {
"uid": 1,
"gid": 1,
2015-08-29 13:15:09 +08:00
"additionalGids": [5, 6]
2015-07-01 06:58:24 +08:00
},
2015-07-01 06:16:51 +08:00
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
2015-08-29 13:19:26 +08:00
"cwd": "/root",
2015-07-01 06:16:51 +08:00
"args": [
"sh"
2016-03-03 03:40:09 +08:00
],
2016-03-03 06:33:38 +08:00
"apparmorProfile": "acme_secure_profile",
"selinuxLabel": "system_u:system_r:svirt_lxc_net_t:s0:c124,c675",
2016-03-03 03:40:09 +08:00
"noNewPrivileges": true,
2017-02-03 06:57:42 +08:00
"capabilities": {
"bounding": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"permitted": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"inheritable": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"effective": [
"CAP_AUDIT_WRITE",
2017-03-07 04:12:41 +08:00
"CAP_KILL"
2017-02-03 06:57:42 +08:00
],
"ambient": [
"CAP_NET_BIND_SERVICE"
]
},
2016-03-10 17:44:09 +08:00
"rlimits": [
{
"type": "RLIMIT_NOFILE",
"hard": 1024,
"soft": 1024
}
2015-07-01 06:16:51 +08:00
]
}
2015-06-25 08:15:48 +08:00
```
2016-04-26 11:03:09 +08:00
### Example (Solaris)
```json
"process": {
"terminal": true,
2016-09-15 04:12:21 +08:00
"consoleSize": {
"height": 25,
"width": 80
},
2016-04-26 11:03:09 +08:00
"user": {
"uid": 1,
"gid": 1,
"additionalGids": [2, 8]
},
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/root",
"args": [
"/usr/bin/bash"
2016-09-15 04:57:38 +08:00
]
}
```
2017-03-03 03:00:31 +08:00
#### <a name="configWindowsUser" />Windows User
2016-09-15 04:57:38 +08:00
For Windows based systems the user structure has the following fields:
2016-09-18 12:59:07 +08:00
* **`username`** (string, OPTIONAL) specifies the user name for the process.
2016-09-15 04:57:38 +08:00
### Example (Windows)
```json
"process": {
"terminal": true,
"user": {
"username": "containeradministrator"
},
"env": [
"VARIABLE=1"
2016-04-26 11:03:09 +08:00
],
2016-09-15 04:57:38 +08:00
"cwd": "c:\\foo",
"args": [
"someapp.exe",
]
2016-04-26 11:03:09 +08:00
}
```
2015-06-25 08:15:48 +08:00
2017-03-03 03:00:31 +08:00
## <a name="configHostname" />Hostname
2015-06-25 08:15:48 +08:00
2017-01-31 04:11:34 +08:00
* **`hostname`** (string, OPTIONAL) specifies the container's hostname as seen by processes running inside the container.
2017-02-10 04:32:39 +08:00
On Linux, for example, this will change the hostname in the [container ](glossary.md#container-namespace ) [UTS namespace][uts-namespace.7].
2017-03-13 17:47:08 +08:00
Depending on your [namespace configuration ](config-linux.md#namespaces ), the container UTS namespace may be the [runtime ](glossary.md#runtime-namespace ) [UTS namespace][uts-namespace.7].
2015-06-25 08:15:48 +08:00
2016-03-17 09:26:12 +08:00
### Example
2015-07-01 06:16:51 +08:00
2015-06-30 02:54:10 +08:00
```json
2015-07-01 06:16:51 +08:00
"hostname": "mrsdalloway"
2015-06-25 08:15:48 +08:00
```
2017-03-03 03:00:31 +08:00
## <a name="configPlatform" />Platform
2015-06-25 08:15:48 +08:00
2017-02-24 14:05:33 +08:00
**`platform`** (object, REQUIRED) specifies the configuration's target platform.
2016-08-03 14:37:47 +08:00
2017-03-13 17:47:08 +08:00
* **`os`** (string, REQUIRED) specifies the operating system family of the container configuration's specified [`root` ](#root ) file system bundle.
2017-01-31 04:11:34 +08:00
The runtime MUST generate an error if it does not support the specified ** `os` **.
2017-04-05 06:52:50 +08:00
Bundles SHOULD use, and runtimes SHOULD understand, ** `os` ** entries listed in the Go Language document for [`GOOS`][go-environment].
If an operating system is not included in the `GOOS` documentation, it SHOULD be submitted to this specification for standardization.
2017-03-13 17:47:08 +08:00
* **`arch`** (string, REQUIRED) specifies the instruction set for which the binaries in the specified [`root` ](#root ) file system bundle have been compiled.
2017-01-31 04:11:34 +08:00
The runtime MUST generate an error if it does not support the specified ** `arch` **.
2017-04-05 06:52:50 +08:00
Values for ** `arch` ** SHOULD use, and runtimes SHOULD understand, ** `arch` ** entries listed in the Go Language document for [`GOARCH`][go-environment].
If an architecture is not included in the `GOARCH` documentation, it SHOULD be submitted to this specification for standardization.
2015-07-01 06:16:51 +08:00
2016-03-17 09:26:12 +08:00
### Example
2015-06-30 02:54:10 +08:00
```json
2015-07-01 06:16:51 +08:00
"platform": {
"os": "linux",
"arch": "amd64"
}
2015-06-25 08:15:48 +08:00
```
2017-03-03 03:00:31 +08:00
## <a name="configPlatformSpecificConfiguration" />Platform-specific configuration
2016-05-03 02:04:39 +08:00
2017-01-31 04:11:34 +08:00
[**`platform.os`** ](#platform ) is used to specify platform-specific configuration.
Runtime implementations MAY support any valid values for platform-specific fields as part of this configuration.
2016-05-03 02:04:39 +08:00
2016-09-18 12:59:07 +08:00
* **`linux`** (object, OPTIONAL) [Linux-specific configuration ](config-linux.md ).
2017-01-31 04:11:34 +08:00
This MAY be set if ** `platform.os` ** is `linux` and MUST NOT be set otherwise.
2016-11-14 13:43:28 +08:00
* **`windows`** (object, OPTIONAL) [Windows-specific configuration ](config-windows.md ).
2017-01-31 04:11:34 +08:00
This MAY be set if ** `platform.os` ** is `windows` and MUST NOT be set otherwise.
* **`solaris`** (object, OPTIONAL) [Solaris-specific configuration ](config-solaris.md ).
This MAY be set if ** `platform.os` ** is `solaris` and MUST NOT be set otherwise.
2016-05-03 02:04:39 +08:00
### Example (Linux)
```json
{
"platform": {
"os": "linux",
"arch": "amd64"
},
"linux": {
"namespaces": [
{
"type": "pid"
}
]
}
}
```
2015-10-06 11:20:31 +08:00
2017-03-03 03:00:31 +08:00
## <a name="configHooks" />Hooks
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-01-31 04:11:34 +08:00
Hooks allow for the configuration of custom actions related to the [lifecycle ](runtime.md#lifecycle ) of the container.
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
config: Explicitly list 'hooks' as optional
And make it omitempty, otherwise:
$ ocitools generate --template <(echo '{}')
$ cat config.json | jq -S .
{
"hooks": {},
...
}
To provide space for the type information and 'optional', I've
shuffled the hook docs to follow our usual:
* **`{property}`** ({type}, {when-needed}) {notes}
format. I've kept the separate event-trigger sections (e.g. "###
Prestart") since they go into more detail on the timing, purpose, and
exit handling for the different events (and that seemed like too much
information to put into the nested lists).
I've replaced the Go reference from 48049d2 (Clarify the semantics of
hook elements, 2015-11-25, #255) with POSIX references (following the
new process docs) to address pushback against referencing Go [1,2] in
favor of POSIX links [3]. Rob Dolin had suggested
"platform-appropriate" wording [4], but it seems like Visual Studio
2015 supports execv [5], and providing an explicit
"platform-appropriate" wiggle seems like it's adding useless
complication.
[1]: https://github.com/opencontainers/runtime-spec/pull/427#discussion_r62362761
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-46
[3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-52
[4]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-54
[5]: https://msdn.microsoft.com/en-us/library/886kc0as.aspx
Signed-off-by: W. Trevor King <wking@tremily.us>
2016-05-06 23:48:36 +08:00
* **`hooks`** (object, OPTIONAL) MAY contain any of the following properties:
2017-03-14 10:22:01 +08:00
* **`prestart`** (array of objects, OPTIONAL) is an array of [pre-start hooks ](#prestart ).
Entries in the array contain the following properties:
* **`path`** (string, REQUIRED) with similar semantics to [IEEE Std 1003.1-2001 `execv` 's *path* ][ieee-1003.1-2001-xsh-exec].
This specification extends the IEEE standard in that ** `path` ** MUST be absolute.
* **`args`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001 `execv` 's *argv* ][ieee-1003.1-2001-xsh-exec].
* **`env`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001's `environ` ][ieee-1003.1-2001-xbd-c8.1].
* **`timeout`** (int, OPTIONAL) is the number of seconds before aborting the hook.
If set, `timeout` MUST be greater than zero.
* **`poststart`** (array of objects, OPTIONAL) is an array of [post-start hooks ](#poststart ).
Entries in the array have the same schema as pre-start entries.
* **`poststop`** (array of objects, OPTIONAL) is an array of [post-stop hooks ](#poststop ).
Entries in the array have the same schema as pre-start entries.
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-01-31 04:11:34 +08:00
Hooks allow users to specify programs to run before or after various lifecycle events.
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
Hooks MUST be called in the listed order.
2017-01-31 04:11:34 +08:00
The [state ](runtime.md#state ) of the container MUST be passed to hooks over stdin so that they may do work appropriate to the current state of the container.
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-03-03 03:00:31 +08:00
### <a name="configHooksPrestart" />Prestart
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
*: Restore hook lifecycle information removed by create/start split
I expect the lifecycle information was removed accidentally in
be594153 (Split create and start, 2016-04-01, #384), because for a
time it seemed like that PR would also be removing hooks. Putting the
lifecycle information back in, I made some tweaks to adjust to the new
environment, for example:
* Put the pre-start hooks after the 'start' call, but before the meat
of the start call (the container-process exec trigger). Folks who
want a post-create hook can add one with that name. I'd like to
have renamed poststop to post-delete to avoid confusion like [1].
But the motivation for keeping hooks was backwards compatibility [2]
so I've left the name alone.
* Put each "...command is invoked..." lifecycle entry in its own list
entry, to match the 'create' list entry.
* Move the rules about what happens on hook failure into the
lifecycle. This matches pre-split entries like:
If any prestart hook fails, then the container MUST be stopped and
the lifecycle continues at step 7.
and avoids respecifying that information in a second location
(config.md).
* I added the warning section to try and follow post-split's generic
"generates an error" approach while respecting the pre-split desire
to see what failed (we had "then an error including the exit code
and the stderr is returned to the caller" and "then an error is
logged").
* I left the state 'id' context out, since Michael didn't want it [3].
* Make runtime.md references to "generate an error" and "log a
warning" links, so readers have an easier time finding more detail
on that wording.
Where I reference a section, I'm still using the auto-generated anchor
for that header and not the anchors which were added in 41839d7 (Merge
pull request #707 from mrunalp/anchor_tags, 2017-03-03) and similar.
Mrunal suggested that the manually-added anchors were mainly intended
for the validation tooling [4].
[1]: https://github.com/opencontainers/runtime-spec/pull/395
Subject: Run post-stop hooks before the container sandbox is deleted.
[2]: https://github.com/opencontainers/runtime-spec/pull/483#issuecomment-240568422
Subject: *: Remove hooks
[3]: https://github.com/opencontainers/runtime-spec/pull/532#discussion_r99232480
Subject: Restore hook language removed by create/start split
[4]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-03-03.log.html#t2017-03-03T18:02:12
Signed-off-by: W. Trevor King <wking@tremily.us>
2016-08-18 07:14:40 +08:00
The pre-start hooks MUST be called after the [`start` ](runtime.md#start ) operation is called but [before the user-specified program command is executed ](runtime.md#lifecycle ).
2017-01-31 04:11:34 +08:00
On Linux, for example, they are called after the container namespaces are created, so they provide an opportunity to customize the container (e.g. the network namespace could be specified in this hook).
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-03-03 03:00:31 +08:00
### <a name="configHooksPoststart" />Poststart
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-05-12 20:56:36 +08:00
The post-start hooks MUST be called [after the user-specified process is executed ](runtime.md#lifecycle ) but before the [`start` ](runtime.md#start ) operation returns.
2017-01-31 04:11:34 +08:00
For example, this hook can notify the user that the container process is spawned.
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-03-03 03:00:31 +08:00
### <a name="configHooksPoststop" />Poststop
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2017-05-12 20:56:36 +08:00
The post-stop hooks MUST be called [after the container is deleted ](runtime.md#lifecycle ) but before the [`delete` ](runtime.md#delete ) operation returns.
2017-01-31 04:11:34 +08:00
Cleanup or debugging functions are examples of such a hook.
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
2016-03-17 09:26:12 +08:00
### Example
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
```json
2016-09-07 13:21:33 +08:00
"hooks": {
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
"prestart": [
{
"path": "/usr/bin/fix-mounts",
"args": ["fix-mounts", "arg1", "arg2"],
"env": [ "key1=value1"]
},
{
"path": "/usr/bin/setup-network"
}
],
"poststart": [
{
2016-04-07 05:07:17 +08:00
"path": "/usr/bin/notify-start",
2016-03-17 07:51:29 +08:00
"timeout": 5
config: Single, unified config file
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-12-29 02:06:40 +08:00
}
],
"poststop": [
{
"path": "/usr/sbin/cleanup.sh",
"args": ["cleanup.sh", "-f"]
}
]
}
```
2017-03-03 03:00:31 +08:00
## <a name="configAnnotations" />Annotations
2016-03-05 03:10:48 +08:00
2016-09-18 12:59:07 +08:00
**`annotations`** (object, OPTIONAL) contains arbitrary metadata for the container.
2016-05-23 14:30:06 +08:00
This information MAY be structured or unstructured.
2017-01-13 23:26:12 +08:00
Annotations MUST be a key-value map.
If there are no annotations then this property MAY either be absent or an empty map.
Keys MUST be strings.
2017-01-13 02:05:06 +08:00
Keys MUST be unique within this map.
Keys MUST NOT be an empty string.
2016-06-27 03:49:13 +08:00
Keys SHOULD be named using a reverse domain notation - e.g. `com.example.myKey` .
Keys using the `org.opencontainers` namespace are reserved and MUST NOT be used by subsequent specifications.
Implementations that are reading/processing this configuration file MUST NOT generate an error if they encounter an unknown annotation key.
2016-03-05 03:10:48 +08:00
2017-01-13 23:26:12 +08:00
Values MUST be strings.
Values MAY be an empty string.
2016-03-05 03:10:48 +08:00
```json
"annotations": {
2016-09-07 13:21:33 +08:00
"com.example.gpu-cores": "2"
2016-03-05 03:10:48 +08:00
}
```
2017-03-03 03:00:31 +08:00
## <a name="configExtensibility" />Extensibility
2016-09-18 06:10:25 +08:00
Implementations that are reading/processing this configuration file MUST NOT generate an error if they encounter an unknown property.
2016-06-27 03:49:13 +08:00
Instead they MUST ignore unknown properties.
2017-02-08 07:13:47 +08:00
## Valid values
Implementations that are reading/processing this configuration file MUST generate an error when invalid or unsupported values are encountered.
Unless support for a valid value is explicitly required, runtimes MAY choose which subset of the valid values it will support.
2015-12-19 04:47:21 +08:00
## Configuration Schema Example
Here is a full example `config.json` for reference.
```json
{
2016-04-07 05:07:17 +08:00
"ociVersion": "0.5.0-dev",
2016-03-10 03:25:49 +08:00
"platform": {
"os": "linux",
"arch": "amd64"
},
"process": {
"terminal": true,
"user": {
"uid": 1,
"gid": 1,
"additionalGids": [
5,
6
]
},
"args": [
"sh"
],
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/",
2017-02-03 06:57:42 +08:00
"capabilities": {
"bounding": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"permitted": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"inheritable": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"effective": [
"CAP_AUDIT_WRITE",
2017-03-07 04:12:41 +08:00
"CAP_KILL"
2017-02-03 06:57:42 +08:00
],
"ambient": [
"CAP_NET_BIND_SERVICE"
]
},
2016-03-10 17:44:09 +08:00
"rlimits": [
2016-04-07 05:07:17 +08:00
{
"type": "RLIMIT_CORE",
"hard": 1024,
"soft": 1024
},
2016-03-10 17:44:09 +08:00
{
"type": "RLIMIT_NOFILE",
"hard": 1024,
"soft": 1024
}
],
2016-04-07 05:07:17 +08:00
"apparmorProfile": "acme_secure_profile",
2017-05-10 00:40:06 +08:00
"oomScoreAdj": 100,
2016-04-07 05:07:17 +08:00
"selinuxLabel": "system_u:system_r:svirt_lxc_net_t:s0:c124,c675",
"noNewPrivileges": true
2016-03-10 03:25:49 +08:00
},
"root": {
"path": "rootfs",
"readonly": true
},
"hostname": "slartibartfast",
"mounts": [
{
"destination": "/proc",
"type": "proc",
"source": "proc"
},
{
"destination": "/dev",
"type": "tmpfs",
"source": "tmpfs",
"options": [
"nosuid",
"strictatime",
"mode=755",
"size=65536k"
]
},
{
"destination": "/dev/pts",
"type": "devpts",
"source": "devpts",
"options": [
"nosuid",
"noexec",
"newinstance",
"ptmxmode=0666",
"mode=0620",
"gid=5"
]
},
{
"destination": "/dev/shm",
"type": "tmpfs",
"source": "shm",
"options": [
"nosuid",
"noexec",
"nodev",
"mode=1777",
"size=65536k"
]
},
{
"destination": "/dev/mqueue",
"type": "mqueue",
"source": "mqueue",
"options": [
"nosuid",
"noexec",
"nodev"
]
},
{
"destination": "/sys",
"type": "sysfs",
"source": "sysfs",
"options": [
"nosuid",
"noexec",
"nodev"
]
},
{
"destination": "/sys/fs/cgroup",
"type": "cgroup",
"source": "cgroup",
"options": [
"nosuid",
"noexec",
"nodev",
"relatime",
"ro"
]
}
],
"hooks": {
"prestart": [
{
2016-04-07 05:07:17 +08:00
"path": "/usr/bin/fix-mounts",
2016-03-10 03:25:49 +08:00
"args": [
2016-04-07 05:07:17 +08:00
"fix-mounts",
"arg1",
"arg2"
2016-03-10 03:25:49 +08:00
],
2016-04-07 05:07:17 +08:00
"env": [
"key1=value1"
]
},
{
"path": "/usr/bin/setup-network"
}
],
"poststart": [
{
"path": "/usr/bin/notify-start",
"timeout": 5
}
],
"poststop": [
{
"path": "/usr/sbin/cleanup.sh",
"args": [
"cleanup.sh",
"-f"
]
2016-03-10 03:25:49 +08:00
}
]
},
"linux": {
2016-04-07 05:07:17 +08:00
"devices": [
{
"path": "/dev/fuse",
"type": "c",
"major": 10,
"minor": 229,
"fileMode": 438,
"uid": 0,
"gid": 0
},
{
"path": "/dev/sda",
"type": "b",
"major": 8,
"minor": 0,
"fileMode": 432,
"uid": 0,
"gid": 0
}
],
2016-04-20 13:16:47 +08:00
"uidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 32000
}
],
"gidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 32000
}
],
2016-04-07 05:07:17 +08:00
"sysctl": {
"net.ipv4.ip_forward": "1",
"net.core.somaxconn": "256"
},
"cgroupsPath": "/myRuntime/myContainer",
2016-03-10 03:25:49 +08:00
"resources": {
2016-04-07 05:07:17 +08:00
"network": {
"classID": 1048577,
"priorities": [
{
"name": "eth0",
"priority": 500
},
{
"name": "eth1",
"priority": 1000
}
]
},
"pids": {
"limit": 32771
},
"hugepageLimits": [
{
"pageSize": "2MB",
"limit": 9223372036854772000
}
],
"memory": {
"limit": 536870912,
"reservation": 536870912,
"swap": 536870912,
"kernel": 0,
"kernelTCP": 0,
"swappiness": 0
},
"cpu": {
"shares": 1024,
"quota": 1000000,
"period": 500000,
"realtimeRuntime": 950000,
"realtimePeriod": 1000000,
"cpus": "2-3",
"mems": "0-7"
},
"disableOOMKiller": false,
2016-03-10 03:25:49 +08:00
"devices": [
{
"allow": false,
"access": "rwm"
2016-04-07 05:07:17 +08:00
},
{
"allow": true,
"type": "c",
"major": 10,
"minor": 229,
"access": "rw"
},
{
"allow": true,
"type": "b",
"major": 8,
"minor": 0,
"access": "r"
}
],
"blockIO": {
"blkioWeight": 10,
"blkioLeafWeight": 10,
"blkioWeightDevice": [
{
"major": 8,
"minor": 0,
"weight": 500,
"leafWeight": 300
},
{
"major": 8,
"minor": 16,
"weight": 500
}
],
"blkioThrottleReadBpsDevice": [
{
"major": 8,
"minor": 0,
"rate": 600
}
],
"blkioThrottleWriteIOPSDevice": [
{
"major": 8,
"minor": 16,
"rate": 300
}
]
}
},
"rootfsPropagation": "slave",
"seccomp": {
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": [
2017-01-14 08:27:24 +08:00
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
2016-04-07 05:07:17 +08:00
],
"syscalls": [
{
2017-01-14 08:27:24 +08:00
"names": [
"getcwd",
"chmod"
],
2017-03-07 14:58:03 +08:00
"action": "SCMP_ACT_ERRNO"
2016-03-10 03:25:49 +08:00
}
]
},
"namespaces": [
{
"type": "pid"
},
{
"type": "network"
},
{
"type": "ipc"
},
{
"type": "uts"
},
{
"type": "mount"
2016-05-28 13:02:35 +08:00
},
{
"type": "user"
},
{
"type": "cgroup"
2016-03-10 03:25:49 +08:00
}
2016-04-07 05:07:17 +08:00
],
"maskedPaths": [
"/proc/kcore",
"/proc/latency_stats",
"/proc/timer_stats",
"/proc/sched_debug"
],
"readonlyPaths": [
"/proc/asound",
"/proc/bus",
"/proc/fs",
"/proc/irq",
"/proc/sys",
"/proc/sysrq-trigger"
2016-04-22 05:01:40 +08:00
],
"mountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c715,c811"
2016-04-07 05:07:17 +08:00
},
"annotations": {
2016-06-27 03:49:13 +08:00
"com.example.key1": "value1",
"com.example.key2": "value2"
2016-03-10 03:25:49 +08:00
}
2015-12-19 04:47:21 +08:00
}
```
2017-02-10 04:32:39 +08:00
[apparmor]: https://wiki.ubuntu.com/AppArmor
2017-05-10 00:40:06 +08:00
[cgroup-v1-memory_2]: https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
2017-02-10 04:32:39 +08:00
[selinux]:http://selinuxproject.org/page/Main_Page
[no-new-privs]: https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt
2017-05-10 00:40:06 +08:00
[procfs_2]: https://www.kernel.org/doc/Documentation/filesystems/proc.txt
2017-02-10 04:32:39 +08:00
[semver-v2.0.0]: http://semver.org/spec/v2.0.0.html
2016-04-30 01:59:45 +08:00
[go-environment]: https://golang.org/doc/install/source#environment
2016-05-20 13:04:52 +08:00
[ieee-1003.1-2001-xbd-c8.1]: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_01
config: Adjust process.args to cite POSIX's execvp
This punts the awkward-to-enforce "MUST be available at the given path
inside of the rootfs" to the kernel, which will do a much better job
of enforcing that constraint than runtime code or a static validator.
It also punts most of the semantics to POSIX, which does a better job
than we'll do at specifying this. The extension is necessary because
POSIX allows argv to be empty. In the DESCRIPTION:
The argument arg0 should point to a filename that is associated with
the process being started by one of the exec functions.
And in RATIONALE:
Early proposals required that the value of argc passed to main() be
"one or greater". This was driven by the same requirement in drafts
of the ISO C standard. In fact, historical implementations have
passed a value of zero when no arguments are supplied to the caller
of the exec functions. This requirement was removed from the ISO C
standard and subsequently removed from this volume of IEEE Std
1003.1-2001 as well. The wording, in particular the use of the word
should, requires a Strictly Conforming POSIX Application to pass at
least one argument to the exec function, thus guaranteeing that argc
be one or greater when invoked by such an application. In fact,
this is good practice, since many existing applications reference
argv[0] without first checking the value of argc.
But with an empty 'args' we will have no process to call (since
process lacks an explicit 'file' analog).
I chose the 2001/2004 POSIX spec for consistency with the existing
reference (which landed in 7ac41c69, config.md: reformat into a
standard style, 2015-06-30, which did not motivate it's use of an
older standard). For 2001 vs. 2004, [1] has:
Abstract: The 2004 edition incorporates Technical Corrigendum Number
1 and Technical Corrigendum 2 addressing problems discovered since
the approval of the 2001 edition. These are mainly due to resolving
integration issues raised by the merger of the Base documents.
and the text in the linked pages uses "IEEE Std 1003.1-2001" for
internal linking.
Rob Dolin had suggested "platform-appropriate" wording [2], but it
seems like Visual Studio 2015 supports execvp [3], and providing an
explicit "platform-appropriate" wiggle seems like it's adding useless
complication.
[1]: http://pubs.opengroup.org/onlinepubs/009695399/mindex.html
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-54
[3]: https://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
Signed-off-by: W. Trevor King <wking@tremily.us>
2016-05-20 13:32:56 +08:00
[ieee-1003.1-2001-xsh-exec]: http://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
2017-02-10 04:32:39 +08:00
[mountvol]: http://ss64.com/nt/mountvol.html
[set-volume-mountpoint]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365561(v=vs.85).aspx
[capabilities.7]: http://man7.org/linux/man-pages/man7/capabilities.7.html
[mount.2]: http://man7.org/linux/man-pages/man2/mount.2.html
[mount.8]: http://man7.org/linux/man-pages/man8/mount.8.html
2016-09-15 05:03:27 +08:00
[mount.8-filesystem-independent]: http://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-INDEPENDENT_MOUNT%20OPTIONS
[mount.8-filesystem-specific]: http://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-SPECIFIC_MOUNT%20OPTIONS
2017-02-10 04:32:39 +08:00
[setrlimit.2]: http://man7.org/linux/man-pages/man2/setrlimit.2.html
2016-07-19 06:53:00 +08:00
[stdin.3]: http://man7.org/linux/man-pages/man3/stdin.3.html
2017-02-10 04:32:39 +08:00
[uts-namespace.7]: http://man7.org/linux/man-pages/man7/namespaces.7.html
2017-05-10 05:56:24 +08:00
[zonecfg.1m]: https://docs.oracle.com/cd/E36784_01/html/E36871/zonecfg-1m.html