jasder
/
runc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request #98 from wking/clarify-idmapping-fields 

Fix IDMapping host / container field confusion
This commit is contained in:
Michael Crosby 2015-07-10 14:08:00 -07:00
parent a80e2961dc 41979ca62c
commit 3c403a265e
5 changed files with 40 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Godeps/Godeps.json generated
View File

@ -1,6 +1,6 @@
{ {
"ImportPath": "github.com/opencontainers/runc", "ImportPath": "github.com/opencontainers/runc",
"GoVersion": "go1.4.1", "GoVersion": "go1.4.2",
"Deps": [ "Deps": [
{ {
"ImportPath": "github.com/Sirupsen/logrus", "ImportPath": "github.com/Sirupsen/logrus",
@ -48,7 +48,7 @@
}, },
{ {
"ImportPath": "github.com/opencontainers/specs", "ImportPath": "github.com/opencontainers/specs",
"Rev": "8fa5eb040abe89f09767c1b249b10757bb431cc2" "Rev": "08873003592da169f89ec7c671ed34e1a2333ef8"
}, },
{ {
"ImportPath": "github.com/syndtr/gocapability/capability", "ImportPath": "github.com/syndtr/gocapability/capability",

27
Godeps/_workspace/src/github.com/opencontainers/specs/config-linux.md generated vendored
View File

@ -1,8 +1,8 @@
# Linux # Linux-specific configuration
The Linux container specification uses various kernel features like namespaces, The Linux container specification uses various kernel features like namespaces,
cgroups, capabilities, LSM, and file system jails to fulfill the spec. cgroups, capabilities, LSM, and file system jails to fulfill the spec.
Additional information is needed for Linux over the default spec configuration Additional information is needed for Linux over the [default spec configuration](config.md)
in order to configure these various kernel features. in order to configure these various kernel features.
## Linux namespaces ## Linux namespaces
@ -118,6 +118,27 @@ For more information, see [the man page](http://man7.org/linux/man-pages/man8/sy
rlimits allow setting resource limits. The type is from the values defined in [the man page](http://man7.org/linux/man-pages/man2/setrlimit.2.html). The kernel enforces the soft limit for a resource while the hard limit acts as a ceiling for that value that could be set by an unprivileged process. rlimits allow setting resource limits. The type is from the values defined in [the man page](http://man7.org/linux/man-pages/man2/setrlimit.2.html). The kernel enforces the soft limit for a resource while the hard limit acts as a ceiling for that value that could be set by an unprivileged process.
## Linux user namespace mappings
```
"uidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 10
}
],
"gidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 10
}
]
```
uid/gid mappings describe the user namespace mappings from the host to the container. *from* is the starting uid/gid on the host to be mapped to *to* which is the starting uid/gid in the container and *count* refers to the number of ids to be mapped. The Linux kernel has a limit of 5 such mappings that can be specified.
## Security ## Security
**TODO:** security profiles **TODO:** security profiles

12
Godeps/_workspace/src/github.com/opencontainers/specs/config.md generated vendored
View File

@ -10,7 +10,7 @@ Below is a detailed description of each field defined in the configuration forma
## Manifest version ## Manifest version
* **version** (string, required) must be in SemVer v2.0.0 format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. * **version** (string, required) must be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OCF specification with which the container bundle complies. The Open Container spec follows semantic versioning and retains forward and backward compatibility within major versions. For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series.
*Example* *Example*
@ -93,7 +93,7 @@ See links for details about [mountvol](http://ss64.com/nt/mountvol.html) and [Se
* **terminal** (bool, optional) specifies whether you want a terminal attached to that process. Defaults to false. * **terminal** (bool, optional) specifies whether you want a terminal attached to that process. Defaults to false.
* **cwd** (string, optional) is the working directory that will be set for the executable. * **cwd** (string, optional) is the working directory that will be set for the executable.
* **env** (array of strings, optional) contains a list of variables that will be set in the process's environment prior to execution. Elements in the array are specified as Strings in the form "KEY=value". The left hand side must consist solely of letters, digits, and underscores '_' as outlined in [IEEE Std 1003.1-2001](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html). * **env** (array of strings, optional) contains a list of variables that will be set in the process's environment prior to execution. Elements in the array are specified as Strings in the form "KEY=value". The left hand side must consist solely of letters, digits, and underscores `_` as outlined in [IEEE Std 1003.1-2001](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html).
* **args** (string, required) executable to launch and any flags as an array. The executable is the first element and must be available at the given path inside of the rootfs. If the executable path is not an absolute path then the search $PATH is interpreted to find the executable. * **args** (string, required) executable to launch and any flags as an array. The executable is the first element and must be available at the given path inside of the rootfs. If the executable path is not an absolute path then the search $PATH is interpreted to find the executable.
The user for the process is a platform-specific structure that allows specific control over which user the process runs as. The user for the process is a platform-specific structure that allows specific control over which user the process runs as.
@ -137,8 +137,8 @@ For Linux-based systems the user structure has the following fields:
## Platform-specific configuration ## Platform-specific configuration
* **os** (string, required) specifies the operating system family this image must run on. Values for arch must be in the list specified by the Go Language document for [$GOOS](https://golang.org/doc/install/source#environment). * **os** (string, required) specifies the operating system family this image must run on. Values for os must be in the list specified by the Go Language document for [`$GOOS`](https://golang.org/doc/install/source#environment).
* **arch** (string, required) specifies the instruction set for which the binaries in the image have been compiled. Values for arch must be in the list specified by the Go Language document for [$GOARCH](https://golang.org/doc/install/source#environment). * **arch** (string, required) specifies the instruction set for which the binaries in the image have been compiled. Values for arch must be in the list specified by the Go Language document for [`$GOARCH`](https://golang.org/doc/install/source#environment).
```json ```json
"platform": { "platform": {
@ -147,6 +147,4 @@ For Linux-based systems the user structure has the following fields:
} }
``` ```
Interpretation of the platform section of the JSON file is used to find which platform specific section may be available in the document. For example if `os` is set to `linux` then the `linux` JSON object SHOULD be found in the `config.json`. Interpretation of the platform section of the JSON file is used to find which platform-specific sections may be available in the document. For example, if `os` is set to `linux`, then a JSON object conforming to the [Linux-specific schema](config-linux.md) SHOULD be found at the key `linux` in the `config.json`.

12
Godeps/_workspace/src/github.com/opencontainers/specs/spec_linux.go generated vendored
View File

@ -52,12 +52,12 @@ type Namespace struct {
// IDMapping specifies uid/gid mappings. // IDMapping specifies uid/gid mappings.
type IDMapping struct { type IDMapping struct {
// From is the uid/gid of the host user or group. // HostID is the uid/gid of the host user or group.
From int32 `json:"from"` HostID int32 `json:"hostID"`
// To is the uid/gid of the container's user or group. // ContainerID is the uid/gid of the container's user or group.
To int32 `json:"to"` ContainerID int32 `json:"containerID"`
// Count is how many uid/gids to map after To. // Size is the length of the range of IDs mapped between the two namespaces.
Count int32 `json:"count"` Size int32 `json:"size"`
} }
// Rlimit type and restrictions. // Rlimit type and restrictions.

6
spec.go
View File

@ -303,9 +303,9 @@ func setupUserNamespace(spec *specs.LinuxSpec, config *configs.Config) error {
config.Namespaces.Add(configs.NEWUSER, "") config.Namespaces.Add(configs.NEWUSER, "")
create := func(m specs.IDMapping) configs.IDMap { create := func(m specs.IDMapping) configs.IDMap {
return configs.IDMap{ return configs.IDMap{
ContainerID: int(m.From), HostID: int(m.HostID),
HostID: int(m.To), ContainerID: int(m.ContainerID),
Size: int(m.Count), Size: int(m.Size),
} }
} }
for _, m := range spec.Linux.UidMappings { for _, m := range spec.Linux.UidMappings {