jasder
/
runc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
runc/config-linux.md

64 lines
3.0 KiB
Markdown
Raw Normal View History

*.md: update TOC and links Some of the docs were not even linked to, and did not have a logic outline for their grouping. Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
2015-09-11 02:36:13 +08:00
# Linux-specific Container Configuration
*: re-org the spec We had an in-person spec discussion, lets separate the spec into some high-level sections to clarify future discussion. Crosby agreed to let me merge to master :)
2015-06-25 08:15:48 +08:00
*.md: markdown formatting Closes https://github.com/opencontainers/specs/issues/83 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
2015-09-09 22:17:06 +08:00
The Linux container specification uses various kernel features like namespaces, cgroups, capabilities, LSM, and file system jails to fulfill the spec.
Additional information is needed for Linux over the [default spec configuration](config.md) in order to configure these various kernel features.
Add linux spec description Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2015-07-01 06:18:40 +08:00
specs: introduce the concept of a runtime.json Based on our discussion in-person yesterday it seems necessary to separate the concept of runtime configuration from application configuration. There are a few motivators: - To support runtime updates of things like cgroups, rlimits, etc we should separate things that are inherently runtime specific from things that are static to the application running in the container. - To support the goal of being able to move a bundle between hosts we should make it clear what parts of the spec are and are not portable between hosts so that upon landing on a new host the non-portable options may be rewritten or removed. - In order to attach a cryptographic identity to a bundle we must not include details in the bundle that are host specific.
2015-07-31 03:17:04 +08:00
## Capabilities
*: re-org the spec We had an in-person spec discussion, lets separate the spec into some high-level sections to clarify future discussion. Crosby agreed to let me merge to master :)
2015-06-25 08:15:48 +08:00
*.md: markdown formatting Closes https://github.com/opencontainers/specs/issues/83 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
2015-09-09 22:17:06 +08:00
Capabilities is an array that specifies Linux capabilities that can be provided to the process inside the container.
Modify the capabilities constants to match header files like other constants Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
2015-09-09 00:57:19 +08:00
Valid values are the strings for capabilities defined in [the man page](http://man7.org/linux/man-pages/man7/capabilities.7.html)
*: re-org the spec We had an in-person spec discussion, lets separate the spec into some high-level sections to clarify future discussion. Crosby agreed to let me merge to master :)
2015-06-25 08:15:48 +08:00
Move linux specific options to linux spec This moves some of the linux specific options like namespaces and devices to the linux config document. It also removes processes as an array and replaces it with a single process. It adds the "platform" struct for OS and Arch and updates many of the examples to match the changes. I also remove some of the redundant windows examples on the portable spec document because they did not add any extra value and many values were the same. Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2015-06-30 02:54:10 +08:00
```json
*: re-org the spec We had an in-person spec discussion, lets separate the spec into some high-level sections to clarify future discussion. Crosby agreed to let me merge to master :)
2015-06-25 08:15:48 +08:00
"capabilities": [
Modify the capabilities constants to match header files like other constants Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
2015-09-09 00:57:19 +08:00
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
Move linux specific options to linux spec This moves some of the linux specific options like namespaces and devices to the linux config document. It also removes processes as an array and replaces it with a single process. It adds the "platform" struct for OS and Arch and updates many of the examples to match the changes. I also remove some of the redundant windows examples on the portable spec document because they did not add any extra value and many values were the same. Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2015-06-30 02:54:10 +08:00
]
*: re-org the spec We had an in-person spec discussion, lets separate the spec into some high-level sections to clarify future discussion. Crosby agreed to let me merge to master :)
2015-06-25 08:15:48 +08:00
```
specs: introduce the concept of a runtime.json Based on our discussion in-person yesterday it seems necessary to separate the concept of runtime configuration from application configuration. There are a few motivators: - To support runtime updates of things like cgroups, rlimits, etc we should separate things that are inherently runtime specific from things that are static to the application running in the container. - To support the goal of being able to move a bundle between hosts we should make it clear what parts of the spec are and are not portable between hosts so that upon landing on a new host the non-portable options may be rewritten or removed. - In order to attach a cryptographic identity to a bundle we must not include details in the bundle that are host specific.
2015-07-31 03:17:04 +08:00
## User namespace mappings
Adds a section for user namespace mappings Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
2015-07-02 05:32:03 +08:00
specs: add json notation Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
2015-07-26 16:08:26 +08:00
```json
Adds a section for user namespace mappings Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
2015-07-02 05:32:03 +08:00
"uidMappings": [
{
spec_linux.go: Rename IDMapping fields to follow syscall.SysProcIDMap 'From' and 'To' are potentially ambiguous for a one-to-one map like this, and there's already an established name convention in SysProcIDMap [1]. This commit removes the mental overhead of two separate naming schemes for the same information. I'd like to drop IDMapping entirely in favor of SysProcIDMap, but SysProcIDMap doesn't give the JSON hints we need for (de)serializing. [1]: https://golang.org/pkg/syscall/#SysProcIDMap
2015-07-08 15:16:51 +08:00
"hostID": 1000,
"containerID": 0,
"size": 10
Adds a section for user namespace mappings Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
2015-07-02 05:32:03 +08:00
}
],
"gidMappings": [
{
spec_linux.go: Rename IDMapping fields to follow syscall.SysProcIDMap 'From' and 'To' are potentially ambiguous for a one-to-one map like this, and there's already an established name convention in SysProcIDMap [1]. This commit removes the mental overhead of two separate naming schemes for the same information. I'd like to drop IDMapping entirely in favor of SysProcIDMap, but SysProcIDMap doesn't give the JSON hints we need for (de)serializing. [1]: https://golang.org/pkg/syscall/#SysProcIDMap
2015-07-08 15:16:51 +08:00
"hostID": 1000,
"containerID": 0,
"size": 10
Adds a section for user namespace mappings Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
2015-07-02 05:32:03 +08:00
}
]
```
specs: introduce the concept of a runtime.json Based on our discussion in-person yesterday it seems necessary to separate the concept of runtime configuration from application configuration. There are a few motivators: - To support runtime updates of things like cgroups, rlimits, etc we should separate things that are inherently runtime specific from things that are static to the application running in the container. - To support the goal of being able to move a bundle between hosts we should make it clear what parts of the spec are and are not portable between hosts so that upon landing on a new host the non-portable options may be rewritten or removed. - In order to attach a cryptographic identity to a bundle we must not include details in the bundle that are host specific.
2015-07-31 03:17:04 +08:00
uid/gid mappings describe the user namespace mappings from the host to the container.
The mappings represent how the bundle `rootfs` expects the user namespace to be setup and the runtime SHOULD NOT modify the permissions on the rootfs to realize the mapping.
*hostID* is the starting uid/gid on the host to be mapped to *containerID* which is the starting uid/gid in the container and *size* refers to the number of ids to be mapped.
There is a limit of 5 mappings which is the Linux kernel hard limit.
config-linux: specify the default devices/filesystems available Fixes #95 Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
2015-09-10 00:36:30 +08:00
## Default Devices and File Systems
The Linux ABI includes both syscalls and several special file paths.
Applications expecting a Linux environment will very likely expect these files paths to be setup correctly.
The following devices and filesystems MUST be made available in each application's filesystem
| Path | Type | Notes |
| ------------ | ------ | ------- |
| /proc | [procfs](https://www.kernel.org/doc/Documentation/filesystems/proc.txt) | |
| /sys | [sysfs](https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt) | |
| /dev/null | [device](http://man7.org/linux/man-pages/man4/null.4.html) | |
| /dev/zero | [device](http://man7.org/linux/man-pages/man4/zero.4.html) | |
| /dev/full | [device](http://man7.org/linux/man-pages/man4/full.4.html) | |
| /dev/random | [device](http://man7.org/linux/man-pages/man4/random.4.html) | |
| /dev/urandom | [device](http://man7.org/linux/man-pages/man4/random.4.html) | |
| /dev/tty | [device](http://man7.org/linux/man-pages/man4/tty.4.html) | |
| /dev/console | [device](http://man7.org/linux/man-pages/man4/console.4.html) | |
| /dev/pts | [devpts](https://www.kernel.org/doc/Documentation/filesystems/devpts.txt) | |
| /dev/ptmx | [device](https://www.kernel.org/doc/Documentation/filesystems/devpts.txt) | Bind-mount or symlink of /dev/pts/ptmx |
| /dev/shm | [tmpfs](https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt) | |