2017-03-03 03:00:31 +08:00
# <a name="containerConfigurationFile" />Container Configuration file
2015-06-25 08:15:48 +08:00
2015-07-31 03:17:04 +08:00
The container's top-level directory MUST contain a configuration file called `config.json` .
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
2015-07-01 06:16:51 +08:00
The configuration file contains metadata necessary to implement standard operations against the container.
This includes the process to run, environment variables to inject, sandboxing features to use, etc.
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
2016-09-18 13:01:53 +08:00
* **`ociVersion`** (string, REQUIRED) MUST be in [SemVer v2.0.0 ](http://semver.org/spec/v2.0.0.html ) 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.
2016-09-18 12:59:07 +08:00
* **`readonly`** (bool, OPTIONAL) If true then the root filesystem MUST be read-only inside the container, defaults to 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-01-31 04:11:34 +08:00
**`mounts`** (array, OPTIONAL) specifies additional mounts beyond [`root` ](#root-configuration ).
2015-09-04 00:56:47 +08:00
The runtime MUST mount entries in the listed order.
2017-01-31 04:11:34 +08:00
For Linux, the parameters are as documented in [the mount system call ](http://man7.org/linux/man-pages/man2/mount.2.html ).
For Solaris, the mount entry corresponds to the 'fs' resource in zonecfg(8).
For Windows, see links for details about [mountvol ](http://ss64.com/nt/mountvol.html ) and [SetVolumeMountPoint ](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365561(v=vs.85 ).aspx).
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).
* Solaris: corresponds to "dir" of the fs resource in zonecfg(8).
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").
* Windows: the type of file system on the volume, e.g. "ntfs".
* Solaris: corresponds to "type" of the fs resource in zonecfg(8).
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-01-31 04:11:34 +08:00
* Windows: the volume name that is the target of the mount point, \\?\Volume\{GUID}\ (on Windows source is called target).
* Solaris: corresponds to "special" of the fs resource in zonecfg(8).
2016-09-18 12:59:07 +08:00
* **`options`** (list of strings, OPTIONAL) Mount options of the filesystem to be used.
2017-01-31 04:11:34 +08:00
* Linux: [supported][mount.8-filesystem-independent] [options][mount.8-filesystem-specific] are listed in [mount(8)][mount.8].
* Solaris: corresponds to "options" of the fs resource in zonecfg(8).
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": [
"myfancymountpoint": {
"destination": "C:\\Users\\crosbymichael\\My Fancy Mount Point\\",
"type": "ntfs",
"source": "\\\\?\\Volume\\{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\\",
"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
2017-01-31 04:11:34 +08:00
**`process`** (object, REQUIRED) specifies the container process.
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].
2016-09-15 04:12:21 +08:00
* **`consoleSize`** (object, OPTIONAL) specifies the console size of the terminal if attached, containing the following properties:
* **`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-02-03 06:57:42 +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) ](http://man7.org/linux/man-pages/man7/capabilities.7.html ) man page.
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-01-31 04:11:34 +08:00
* **`type`** (string, REQUIRED) - the platform resource being limited, for example on Linux as defined in the [SETRLIMIT(2) ](http://man7.org/linux/man-pages/man2/setrlimit.2.html ) man page.
* **`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-01-31 04:11:34 +08:00
As an example, the ['no_new_privs' kernel doc ](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt ) has more information on how this is achieved using a prctl system call on Linux.
For Linux-based systems the process structure supports the following process specific fields.
* **`apparmorProfile`** (string, OPTIONAL) specifies the name of the AppArmor profile to be applied to processes in the container.
For more information about AppArmor, see [AppArmor documentation ](https://wiki.ubuntu.com/AppArmor )
* **`selinuxLabel`** (string, OPTIONAL) specifies the SELinux label to be applied to the processes in the container.
For more information about SELinux, see [SELinux documentation ](http://selinuxproject.org/page/Main_Page )
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
2016-09-18 13:01:53 +08:00
* **`uid`** (int, REQUIRED) specifies the user ID in the [container namespace][container-namespace].
* **`gid`** (int, REQUIRED) specifies the group ID in the [container namespace][container-namespace].
2016-09-18 12:59:07 +08:00
* **`additionalGids`** (array of ints, OPTIONAL) specifies additional group IDs (in the [container namespace][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",
"CAP_KILL",
],
"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.
On Linux, for example, this will change the hostname in the [container][container-namespace] [UTS namespace][uts-namespace].
2017-01-12 07:05:07 +08:00
Depending on your [namespace configuration ](config-linux.md#namespaces ), the container UTS namespace may be the [runtime UTS namespace][runtime-namespace].
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-01-31 04:11:34 +08:00
* **`os`** (string, REQUIRED) specifies the operating system family of the container configuration's specified [`root` ](#root-configuration ) file system bundle.
The runtime MUST generate an error if it does not support the specified ** `os` **.
2016-05-20 14:55:01 +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-01-31 04:11:34 +08:00
* **`arch`** (string, REQUIRED) specifies the instruction set for which the binaries in the specified [`root` ](#root-configuration ) file system bundle have been compiled.
The runtime MUST generate an error if it does not support the specified ** `arch` **.
2016-05-20 14:55:01 +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.
Implementations MUST error out when invalid values are encountered and MUST generate an error message and error out when encountering valid values it chooses to not support.
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:
* **`prestart`** (array, 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.
2017-02-09 09:45:42 +08:00
* **`args`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001 `execv` 's *argv* ][ieee-1003.1-2001-xsh-exec].
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
* **`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.
* **`poststart`** (array, OPTIONAL) is an array of [post-start hooks ](#poststart ).
Entries in the array have the same schema as pre-start entries.
* **`poststop`** (array, 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
2017-01-31 04:11:34 +08:00
The pre-start hooks MUST be called after the container has been created, but before the user supplied command is executed.
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-01-31 04:11:34 +08:00
If a hook returns a non-zero exit code, an error including the exit code and the stderr MUST be returned to the caller and the container MUST be destroyed.
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-01-31 04:11:34 +08:00
The post-start hooks MUST be called after the user process is started.
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-01-31 04:11:34 +08:00
If a hook returns a non-zero exit code, then an error MUST be logged and the remaining hooks are executed.
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-01-31 04:11:34 +08:00
The post-stop hooks MUST be called after the container process is stopped.
Cleanup or debugging functions are examples of such a hook.
If a hook returns a non-zero exit code, then an error MUST be logged and the remaining hooks are executed.
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.
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",
"CAP_KILL",
],
"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",
"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
}
],
"oomScoreAdj": 100,
"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"
],
"action": "SCMP_ACT_ERRNO",
"comment": "stop exploit x"
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
}
```
2016-04-30 01:59:45 +08:00
[container-namespace]: glossary.md#container-namespace
[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
2016-04-30 12:07:00 +08:00
[runtime-namespace]: glossary.md#runtime-namespace
2015-10-06 11:20:31 +08:00
[uts-namespace]: http://man7.org/linux/man-pages/man7/namespaces.7.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
2016-07-22 14:06:54 +08:00
[mount.8]: http://man7.org/linux/man-pages/man8/mount.8.html
2016-07-19 06:53:00 +08:00
[stdin.3]: http://man7.org/linux/man-pages/man3/stdin.3.html
