runc/config_linux.go

326 lines
12 KiB
Go
Raw Normal View History

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"
// 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"`
}
// User specifies linux specific user and group information for the container's
// main process.
type User struct {
// UID is the user id.
UID uint32 `json:"uid"`
// GID is the group id.
GID uint32 `json:"gid"`
// AdditionalGids are additional group ids set for the container's process.
AdditionalGids []uint32 `json:"additionalGids,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
// 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.
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.
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"`
}