In json, os.FileMode would be presented as a uint32, which
is decimal. Otherwise we'll get error:
`invalid character '6' after object key:value pair`
when unmarshal the json file.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Fixes: opencontainers/runc#566
For type rune, we can assign char as 'c' in struct, but after
marshal, it'll be presented as int32. So in json config it needs
to be presented as a number which is not friendly to be identified.
Change it to string so that you can actually write "b", "c" in json
spec and you can easily know what type of device it is.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
With 34a9304a (Merge branch 'for-4.5' of
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup, 2016-01-13,
[1]), Linux restructured their cgroups documentation. This updated
all of our Documentation/cgroups references to match the new layout,
using reference-style links [2] which let us collect link label
definitions at the bottom of the file. That makes the spec source
easier to read (no distracting URLs in the middle of a sentence) and
makes the URLs easier to update (only one place to check / fix).
[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34a9304a96d6351c2d35dcdc9293258378fc0bd8
[2]: http://daringfireball.net/projects/markdown/syntax#link
Signed-off-by: W. Trevor King <wking@tremily.us>
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>
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>
The general rule seems to be:
If Go's default value has the same semantics we'd use for an unset
value, don't bother with a pointer.
I'm not sure how well that squares with [1]:
We want a consistent way to identify unset settings.
But if the falsy values count as "unset", maybe the "null is a
consistent identifier for unset" approach was never really viable.
Qiang points out that pointers are required to opt-out of boolean
settings where both true and false would require action [2], so I've
worded the exception to only apply when the Go default for the type is
expicitly a no-op in the spec.
I'm also not sure if the new style extends to integers where zero has
the same semantics as unset values. It sounds like Michael was ok
with no pointers for those values [3], but OOMScoreAdj (where zero
clearly means "do nothing") got a pointer in #233 [4]. More clarity
on the threshold would be nice; in this commit I've laid out the logic
and not explicitly listed the types it applies to.
[1]: https://github.com/opencontainers/specs/pull/233#discussion_r47829711
[2]: https://github.com/opencontainers/specs/pull/317/files#r50932706
[3]: https://github.com/opencontainers/specs/pull/233#issuecomment-155250592
[4]: https://github.com/opencontainers/specs/pull/233/files#diff-34c30be66233f08b447fb608ea0e66bbR206
Signed-off-by: W. Trevor King <wking@tremily.us>
This is a security setting that could be used to prevent processes in the
container from gaining additional privileges.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Lets call out some users directly and give them titles. Then define what
they is trying to do.
Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
pandoc/LaTeX is not happy with this shady character.
```
! Package inputenc Error: Unicode char \u8:↔ not set up for use with
LaTeX.
```
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
For now, just vet and lint. But would like to include the commit
validator, once a good range is selectable.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
After thorough discussion, even though a reasonable default is "/", for
platform independence, leave this up to the bundle author.
Also, by this variable being present it makes things explicit for the
runtime.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
We discussed this in the face to face meeting and agreed
that it makes sense to keep the rootfs as is for flexibility.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Mrunal Patel
Rob Dolin (MSFT)
Qiang Huang
Alexander Morozov
Doug Davis
Michael Crosby
Vish Kannan
Vincent Batts
W. Trevor King
Mrunal Patel
Brandon Philips
Mrunal Patel
Doug Davis