2015-07-31 03:17:04 +08:00
|
|
|
package specs
|
|
|
|
|
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
|
|
|
import "os"
|
|
|
|
|
|
|
|
// LinuxStateDirectory holds the container's state information
|
|
|
|
const LinuxStateDirectory = "/run/opencontainer/containers"
|
|
|
|
|
2015-07-31 03:17:04 +08:00
|
|
|
// LinuxSpec is the full specification for linux containers.
|
|
|
|
type LinuxSpec struct {
|
|
|
|
Spec
|
|
|
|
// Linux is platform specific configuration for linux based containers.
|
|
|
|
Linux Linux `json:"linux"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Linux contains platform specific configuration for linux based containers.
|
|
|
|
type Linux struct {
|
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
|
|
|
// UIDMapping specifies user mappings for supporting user namespaces on linux.
|
|
|
|
UIDMappings []IDMapping `json:"uidMappings,omitempty"`
|
|
|
|
// GIDMapping specifies group mappings for supporting user namespaces on linux.
|
|
|
|
GIDMappings []IDMapping `json:"gidMappings,omitempty"`
|
|
|
|
// Rlimits specifies rlimit options to apply to the container's process.
|
|
|
|
Rlimits []Rlimit `json:"rlimits,omitempty"`
|
|
|
|
// Sysctl are a set of key value pairs that are set for the container on start
|
|
|
|
Sysctl map[string]string `json:"sysctl,omitempty"`
|
|
|
|
// Resources contain cgroup information for handling resource constraints
|
|
|
|
// for the container
|
|
|
|
Resources *Resources `json:"resources,omitempty"`
|
|
|
|
// CgroupsPath specifies the path to cgroups that are created and/or joined by the container.
|
|
|
|
// The path is expected to be relative to the cgroups mountpoint.
|
|
|
|
// If resources are specified, the cgroups at CgroupsPath will be updated based on resources.
|
|
|
|
CgroupsPath *string `json:"cgroupsPath,omitempty"`
|
|
|
|
// Namespaces contains the namespaces that are created and/or joined by the container
|
|
|
|
Namespaces []Namespace `json:"namespaces"`
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
// Devices are a list of device nodes that are created for 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
|
|
|
Devices []Device `json:"devices"`
|
|
|
|
// Seccomp specifies the seccomp security settings for the container.
|
|
|
|
Seccomp Seccomp `json:"seccomp"`
|
|
|
|
// RootfsPropagation is the rootfs mount propagation mode for the container.
|
|
|
|
RootfsPropagation string `json:"rootfsPropagation,omitempty"`
|
2015-07-31 03:17:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// User specifies linux specific user and group information for the container's
|
|
|
|
// main process.
|
|
|
|
type User struct {
|
2015-09-01 05:55:20 +08:00
|
|
|
// UID is the user id.
|
2015-10-07 02:40:46 +08:00
|
|
|
UID uint32 `json:"uid"`
|
2015-09-01 05:55:20 +08:00
|
|
|
// GID is the group id.
|
2015-10-07 02:40:46 +08:00
|
|
|
GID uint32 `json:"gid"`
|
2015-07-31 03:17:04 +08:00
|
|
|
// AdditionalGids are additional group ids set for the container's process.
|
2015-12-23 18:52:47 +08:00
|
|
|
AdditionalGids []uint32 `json:"additionalGids,omitempty"`
|
2015-07-31 03:17:04 +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
|
|
|
|
|
|
|
// Namespace is the configuration for a linux namespace
|
|
|
|
type Namespace struct {
|
|
|
|
// Type is the type of Linux namespace
|
|
|
|
Type NamespaceType `json:"type"`
|
|
|
|
// Path is a path to an existing namespace persisted on disk that can be joined
|
|
|
|
// and is of the same type
|
|
|
|
Path string `json:"path,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// NamespaceType is one of the linux namespaces
|
|
|
|
type NamespaceType string
|
|
|
|
|
|
|
|
const (
|
|
|
|
// PIDNamespace for isolating process IDs
|
|
|
|
PIDNamespace NamespaceType = "pid"
|
|
|
|
// NetworkNamespace for isolating network devices, stacks, ports, etc
|
|
|
|
NetworkNamespace = "network"
|
|
|
|
// MountNamespace for isolating mount points
|
|
|
|
MountNamespace = "mount"
|
|
|
|
// IPCNamespace for isolating System V IPC, POSIX message queues
|
|
|
|
IPCNamespace = "ipc"
|
|
|
|
// UTSNamespace for isolating hostname and NIS domain name
|
|
|
|
UTSNamespace = "uts"
|
|
|
|
// UserNamespace for isolating user and group IDs
|
|
|
|
UserNamespace = "user"
|
|
|
|
)
|
|
|
|
|
|
|
|
// IDMapping specifies UID/GID mappings
|
|
|
|
type IDMapping struct {
|
|
|
|
// HostID is the UID/GID of the host user or group
|
|
|
|
HostID uint32 `json:"hostID"`
|
|
|
|
// ContainerID is the UID/GID of the container's user or group
|
|
|
|
ContainerID uint32 `json:"containerID"`
|
|
|
|
// Size is the length of the range of IDs mapped between the two namespaces
|
|
|
|
Size uint32 `json:"size"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Rlimit type and restrictions
|
|
|
|
type Rlimit struct {
|
|
|
|
// Type of the rlimit to set
|
|
|
|
Type string `json:"type"`
|
|
|
|
// Hard is the hard limit for the specified type
|
|
|
|
Hard uint64 `json:"hard"`
|
|
|
|
// Soft is the soft limit for the specified type
|
|
|
|
Soft uint64 `json:"soft"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// HugepageLimit structure corresponds to limiting kernel hugepages
|
|
|
|
type HugepageLimit struct {
|
|
|
|
// Pagesize is the hugepage size
|
|
|
|
Pagesize *string `json:"pageSize,omitempty"`
|
|
|
|
// Limit is the limit of "hugepagesize" hugetlb usage
|
|
|
|
Limit *uint64 `json:"limit,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// InterfacePriority for network interfaces
|
|
|
|
type InterfacePriority struct {
|
|
|
|
// Name is the name of the network interface
|
|
|
|
Name string `json:"name"`
|
|
|
|
// Priority for the interface
|
|
|
|
Priority uint32 `json:"priority"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// blockIODevice holds major:minor format supported in blkio cgroup
|
|
|
|
type blockIODevice struct {
|
|
|
|
// Major is the device's major number.
|
|
|
|
Major int64 `json:"major"`
|
|
|
|
// Minor is the device's minor number.
|
|
|
|
Minor int64 `json:"minor"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// WeightDevice struct holds a `major:minor weight` pair for blkioWeightDevice
|
|
|
|
type WeightDevice struct {
|
|
|
|
blockIODevice
|
|
|
|
// Weight is the bandwidth rate for the device, range is from 10 to 1000
|
|
|
|
Weight *uint16 `json:"weight,omitempty"`
|
|
|
|
// LeafWeight is the bandwidth rate for the device while competing with the cgroup's child cgroups, range is from 10 to 1000, CFQ scheduler only
|
|
|
|
LeafWeight *uint16 `json:"leafWeight,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// ThrottleDevice struct holds a `major:minor rate_per_second` pair
|
|
|
|
type ThrottleDevice struct {
|
|
|
|
blockIODevice
|
|
|
|
// Rate is the IO rate limit per cgroup per device
|
|
|
|
Rate *uint64 `json:"rate,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// BlockIO for Linux cgroup 'blkio' resource management
|
|
|
|
type BlockIO struct {
|
|
|
|
// Specifies per cgroup weight, range is from 10 to 1000
|
|
|
|
Weight *uint16 `json:"blkioWeight,omitempty"`
|
|
|
|
// Specifies tasks' weight in the given cgroup while competing with the cgroup's child cgroups, range is from 10 to 1000, CFQ scheduler only
|
|
|
|
LeafWeight *uint16 `json:"blkioLeafWeight,omitempty"`
|
|
|
|
// Weight per cgroup per device, can override BlkioWeight
|
|
|
|
WeightDevice []WeightDevice `json:"blkioWeightDevice,omitempty"`
|
|
|
|
// IO read rate limit per cgroup per device, bytes per second
|
|
|
|
ThrottleReadBpsDevice []ThrottleDevice `json:"blkioThrottleReadBpsDevice,omitempty"`
|
|
|
|
// IO write rate limit per cgroup per device, bytes per second
|
|
|
|
ThrottleWriteBpsDevice []ThrottleDevice `json:"blkioThrottleWriteBpsDevice,omitempty"`
|
|
|
|
// IO read rate limit per cgroup per device, IO per second
|
|
|
|
ThrottleReadIOPSDevice []ThrottleDevice `json:"blkioThrottleReadIOPSDevice,omitempty"`
|
|
|
|
// IO write rate limit per cgroup per device, IO per second
|
|
|
|
ThrottleWriteIOPSDevice []ThrottleDevice `json:"blkioThrottleWriteIOPSDevice,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Memory for Linux cgroup 'memory' resource management
|
|
|
|
type Memory struct {
|
|
|
|
// Memory limit (in bytes).
|
|
|
|
Limit *uint64 `json:"limit,omitempty"`
|
|
|
|
// Memory reservation or soft_limit (in bytes).
|
|
|
|
Reservation *uint64 `json:"reservation,omitempty"`
|
|
|
|
// Total memory limit (memory + swap).
|
|
|
|
Swap *uint64 `json:"swap,omitempty"`
|
|
|
|
// Kernel memory limit (in bytes).
|
|
|
|
Kernel *uint64 `json:"kernel,omitempty"`
|
|
|
|
// Kernel memory limit for tcp (in bytes)
|
|
|
|
KernelTCP *uint64 `json:"kernelTCP"`
|
|
|
|
// How aggressive the kernel will swap memory pages. Range from 0 to 100.
|
|
|
|
Swappiness *uint64 `json:"swappiness,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// CPU for Linux cgroup 'cpu' resource management
|
|
|
|
type CPU struct {
|
|
|
|
// CPU shares (relative weight (ratio) vs. other cgroups with cpu shares).
|
|
|
|
Shares *uint64 `json:"shares,omitempty"`
|
|
|
|
// CPU hardcap limit (in usecs). Allowed cpu time in a given period.
|
|
|
|
Quota *uint64 `json:"quota,omitempty"`
|
|
|
|
// CPU period to be used for hardcapping (in usecs).
|
|
|
|
Period *uint64 `json:"period,omitempty"`
|
|
|
|
// How much time realtime scheduling may use (in usecs).
|
|
|
|
RealtimeRuntime *uint64 `json:"realtimeRuntime,omitempty"`
|
|
|
|
// CPU period to be used for realtime scheduling (in usecs).
|
|
|
|
RealtimePeriod *uint64 `json:"realtimePeriod,omitempty"`
|
|
|
|
// CPUs to use within the cpuset. Default is to use any CPU available.
|
|
|
|
Cpus *string `json:"cpus,omitempty"`
|
|
|
|
// List of memory nodes in the cpuset. Default is to use any available memory node.
|
|
|
|
Mems *string `json:"mems,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Pids for Linux cgroup 'pids' resource management (Linux 4.3)
|
|
|
|
type Pids struct {
|
|
|
|
// Maximum number of PIDs. Default is "no limit".
|
|
|
|
Limit *int64 `json:"limit,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Network identification and priority configuration
|
|
|
|
type Network struct {
|
|
|
|
// Set class identifier for container's network packets
|
|
|
|
ClassID *uint32 `json:"classID"`
|
|
|
|
// Set priority of network traffic for container
|
|
|
|
Priorities []InterfacePriority `json:"priorities,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Resources has container runtime resource constraints
|
|
|
|
type Resources struct {
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
// Devices are a list of device rules for the whitelist controller
|
|
|
|
Devices []DeviceCgroup `json:"devices"`
|
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
|
|
|
// DisableOOMKiller disables the OOM killer for out of memory conditions
|
|
|
|
DisableOOMKiller *bool `json:"disableOOMKiller,omitempty"`
|
|
|
|
// Specify an oom_score_adj for the container.
|
|
|
|
OOMScoreAdj *int `json:"oomScoreAdj,omitempty"`
|
|
|
|
// Memory restriction configuration
|
|
|
|
Memory *Memory `json:"memory,omitempty"`
|
|
|
|
// CPU resource restriction configuration
|
|
|
|
CPU *CPU `json:"cpu,omitempty"`
|
|
|
|
// Task resource restriction configuration.
|
|
|
|
Pids *Pids `json:"pids,omitempty"`
|
|
|
|
// BlockIO restriction configuration
|
|
|
|
BlockIO *BlockIO `json:"blockIO,omitempty"`
|
|
|
|
// Hugetlb limit (in bytes)
|
|
|
|
HugepageLimits []HugepageLimit `json:"hugepageLimits,omitempty"`
|
|
|
|
// Network restriction configuration
|
|
|
|
Network *Network `json:"network,omitempty"`
|
|
|
|
}
|
|
|
|
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
// Device represents the mknod information for a Linux special device file
|
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
|
|
|
type Device struct {
|
|
|
|
// Path to the device.
|
|
|
|
Path string `json:"path"`
|
|
|
|
// Device type, block, char, etc.
|
2016-02-23 13:33:57 +08:00
|
|
|
Type string `json:"type"`
|
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
|
|
|
// Major is the device's major number.
|
|
|
|
Major int64 `json:"major"`
|
|
|
|
// Minor is the device's minor number.
|
|
|
|
Minor int64 `json:"minor"`
|
|
|
|
// FileMode permission bits for the device.
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
FileMode *os.FileMode `json:"fileMode,omitempty"`
|
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
|
|
|
// UID of the device.
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
UID *uint32 `json:"uid,omitempty"`
|
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
|
|
|
// Gid of the device.
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
GID *uint32 `json:"gid,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// DeviceCgroup represents a device rule for the whitelist controller
|
|
|
|
type DeviceCgroup struct {
|
|
|
|
// Allow or deny
|
|
|
|
Allow bool `json:"allow"`
|
|
|
|
// Device type, block, char, etc.
|
2016-02-23 13:33:57 +08:00
|
|
|
Type *string `json:"type,omitempty"`
|
runtime-config-linux: Separate mknod from cgroups
With mknod entries in linux.devices and cgroups entries in
linux.resources.devices. Background discussion in [1].
For specifying device cgroups independent of device creation. This
makes it easy to distinguish between configs that call for cgroup
adjustments (which have linux.resources entries) from those that
don't. Without this split, folks interested in making that
distinction would have to parse the device section to determine if it
included cgroup changes. This will also make it easy to drop either
portion (mknod [2] or cgroups [3]) independently of the other if the
project decides to do so.
Using seperate sections for mknod and cgroups also allows us to avoid
the complicated validation rules needed for the combined format
mknod/cgroup [4].
Now that there is a section specific to supplying devices, I shifted
the default device listing over from config-linux [5]. The /dev/ptmx
entry is a bit awkward, since it's not a device, but it seemed to fit
better over here. But I would also be fine leaving it with the other
mounts in config-linux.
fileMode, uid, and gid are optional, because mknod(2) doesn't need
them and specifies the handling when they aren't set [6,7].
Similarly, major/minor numbers are only required for S_IFCHR and
S_IFBLK [6]. I've left off wording about required runtime behavior
for unset values, because I'd rather address that with a blanket rule
[8].
For the cgroup, access is optional because the kernel docs show an
example that doesn't write an access field to the devices.deny file
[9]. The current kernel docs don't go into much detail on this
behavior (I expect unset and 'rwm' are equivalent), but if the kernel
doesn't need a value written, the spec should get out of the way and
allow users to not specify a value.
The reference links are sorted into two blocks, with kernel-doc links
sorted alphabetically followed by man pages sorted alphabetically by
section. The cgroup link is new since 2016-01-13 [10].
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/y_Fsa2_jJaM
Subject: Separate config entries for device mknod and cgroups?
Date: Mon, 5 Oct 2015 12:46:55 -0700
Message-ID: <20151005194655.GN28418@odin.tremily.us>
[2]: https://github.com/opencontainers/specs/pull/98
[3]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qWHoKs8Fsrk
Subject: removal of cgroups from the OCI Linux spec
Date: Wed, 28 Oct 2015 17:01:59 +0000
Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com>
[4]: https://github.com/opencontainers/specs/pull/101
[5]: https://github.com/opencontainers/specs/pull/171#discussion_r41190655
[6]: http://man7.org/linux/man-pages/man2/mknod.2.html#DESCRIPTION
[7]: https://github.com/opencontainers/specs/pull/298/files#r51053835
[8]: https://github.com/opencontainers/specs/pull/285#issuecomment-167823651
[9]: https://kernel.org/doc/Documentation/cgroup-v1/devices.txt
[10]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
Signed-off-by: W. Trevor King <wking@tremily.us>
2015-08-07 02:27:50 +08:00
|
|
|
// Major is the device's major number.
|
|
|
|
Major *int64 `json:"major,omitempty"`
|
|
|
|
// Minor is the device's minor number.
|
|
|
|
Minor *int64 `json:"minor,omitempty"`
|
|
|
|
// Cgroup access permissions format, rwm.
|
|
|
|
Access *string `json:"access,omitempty"`
|
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
|
|
|
}
|
|
|
|
|
|
|
|
// Seccomp represents syscall restrictions
|
|
|
|
type Seccomp struct {
|
|
|
|
DefaultAction Action `json:"defaultAction"`
|
|
|
|
Architectures []Arch `json:"architectures"`
|
|
|
|
Syscalls []Syscall `json:"syscalls,omitempty"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Arch used for additional architectures
|
|
|
|
type Arch string
|
|
|
|
|
|
|
|
// Additional architectures permitted to be used for system calls
|
|
|
|
// By default only the native architecture of the kernel is permitted
|
|
|
|
const (
|
|
|
|
ArchX86 Arch = "SCMP_ARCH_X86"
|
|
|
|
ArchX86_64 Arch = "SCMP_ARCH_X86_64"
|
|
|
|
ArchX32 Arch = "SCMP_ARCH_X32"
|
|
|
|
ArchARM Arch = "SCMP_ARCH_ARM"
|
|
|
|
ArchAARCH64 Arch = "SCMP_ARCH_AARCH64"
|
|
|
|
ArchMIPS Arch = "SCMP_ARCH_MIPS"
|
|
|
|
ArchMIPS64 Arch = "SCMP_ARCH_MIPS64"
|
|
|
|
ArchMIPS64N32 Arch = "SCMP_ARCH_MIPS64N32"
|
|
|
|
ArchMIPSEL Arch = "SCMP_ARCH_MIPSEL"
|
|
|
|
ArchMIPSEL64 Arch = "SCMP_ARCH_MIPSEL64"
|
|
|
|
ArchMIPSEL64N32 Arch = "SCMP_ARCH_MIPSEL64N32"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Action taken upon Seccomp rule match
|
|
|
|
type Action string
|
|
|
|
|
|
|
|
// Define actions for Seccomp rules
|
|
|
|
const (
|
|
|
|
ActKill Action = "SCMP_ACT_KILL"
|
|
|
|
ActTrap Action = "SCMP_ACT_TRAP"
|
|
|
|
ActErrno Action = "SCMP_ACT_ERRNO"
|
|
|
|
ActTrace Action = "SCMP_ACT_TRACE"
|
|
|
|
ActAllow Action = "SCMP_ACT_ALLOW"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Operator used to match syscall arguments in Seccomp
|
|
|
|
type Operator string
|
|
|
|
|
|
|
|
// Define operators for syscall arguments in Seccomp
|
|
|
|
const (
|
|
|
|
OpNotEqual Operator = "SCMP_CMP_NE"
|
|
|
|
OpLessThan Operator = "SCMP_CMP_LT"
|
|
|
|
OpLessEqual Operator = "SCMP_CMP_LE"
|
|
|
|
OpEqualTo Operator = "SCMP_CMP_EQ"
|
|
|
|
OpGreaterEqual Operator = "SCMP_CMP_GE"
|
|
|
|
OpGreaterThan Operator = "SCMP_CMP_GT"
|
|
|
|
OpMaskedEqual Operator = "SCMP_CMP_MASKED_EQ"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Arg used for matching specific syscall arguments in Seccomp
|
|
|
|
type Arg struct {
|
|
|
|
Index uint `json:"index"`
|
|
|
|
Value uint64 `json:"value"`
|
|
|
|
ValueTwo uint64 `json:"valueTwo"`
|
|
|
|
Op Operator `json:"op"`
|
|
|
|
}
|
|
|
|
|
|
|
|
// Syscall is used to match a syscall in Seccomp
|
|
|
|
type Syscall struct {
|
|
|
|
Name string `json:"name"`
|
|
|
|
Action Action `json:"action"`
|
|
|
|
Args []Arg `json:"args,omitempty"`
|
|
|
|
}
|