This is style information, even though it's about the spec and not
about the behavior covered by the spec. The Go-pointer rule is also
about more peripheral stuff though, and the README has a lot of stuff
in it, so it seems like a better fit after the move.
Signed-off-by: W. Trevor King <wking@tremily.us>
Fixes#320
This adds the maskedPaths and readonlyPaths fields to the spec so that
proper masking and setting of files in /proc can be configured.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
So that runtimes don't lock up forever waiting on a hook to return I
added a timeout field. This allows the author to specify the timeout in
seconds that they want the hook to run before aborting the hook and
container execution.
I think the hook is the proper place to specify a timeouot like this
because any type of overall timeout in the runtime will probably not
work for all hooks and will not be flexable enough.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Avoid trouble with situations like:
# mount --bind /mnt/test /mnt/test
# mount --make-rprivate /mnt/test
# touch /mnt/test/mnt /mnt/test/user
# mount --bind /proc/123/ns/mnt /mnt/test/mnt
# mount --bind /proc/123/ns/user /mnt/test/user
# nsenter --mount=/proc/123/ns/mnt --user /proc/123/ns/user sh
which uses the required private mount for binding mount namespace
references [1,2,3]. We want to avoid:
1. Runtime opens /mnt/test/mnt as fd 3.
2. Runtime joins the mount namespace referenced by fd 3.
3. Runtime fails to open /mnt/test/user, because /mnt/test is not
visible in the current mount namespace.
and instead get runtime authors to setup flows like:
1. Runtime opens /mnt/test/mnt as fd 3.
2. Runtime opens /mnt/test/user as fd 4.
3. Runtime joins the mount namespace referenced by fd 3.
4. Runtime joins the user namespace referenced by fd 4.
This also applies to new namespace creation. We want to avoid:
1. Runtime clones a container process with a new mount namespace.
2c. Container process fails to open /mnt/test/user, because /mnt/test
is not visible in the current mount namespace.
in favor of something like:
1. Runtime opens /mnt/test/user as fd 3.
2. Runtime clones a container process with a new mount namespace.
3h. Host process closes unneeded fd 3.
3c. Container process joins the user namespace referenced by fd 3.
I also define runtime and container namespaces, so we have consistent
terminology. I prefer:
* host namespace: a namespace you are in when you invoke the runtime
* host process: the runtime process invoked by the user
* container process: the process created by a clone call in the host
process which will eventually execute the user-configured process.
Both the host and container processes are running runtime code
(although the container process eventually transitions to
user-configured code), so I find "runtime process", "runtime
namespace", etc. to be imprecise. However, the maintainer consensus
is for "runtime namespace" [4,5], so that's what we're going with
here.
[1]: http://karelzak.blogspot.com/2015/04/persistent-namespaces.html
[2]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ce5d2b1a8fde84c0eebe70652cf28b9beda6b4e
[3]: http://mid.gmane.org/87haeahkzc.fsf@xmission.com
[4]: https://github.com/opencontainers/specs/pull/275#discussion_r48057211
[5]: https://github.com/opencontainers/specs/pull/275#discussion_r48324264
Signed-off-by: W. Trevor King <wking@tremily.us>
By using ffjson for json encoding we can reduce the time for encoding
and decoding.
Without:
BenchmarkMarsalSpec-4 100000 18276 ns/op
BenchmarkUnmarshal-4 30000 55115 ns/op
With:
BenchmarkMarsalSpec-4 100000 13649 ns/op
BenchmarkUnmarshal-4 50000 24747 ns/op
This is a reduces time about 25% on marshal and 50% on unmarshal.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This adds basic benchmark tests for the performace of marshaling and
unmarshaling the spec into json. These tests are helpful to optimize
the performace because the main way the spec is consumed is via json.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Also:
* Update the link to Go bindings after 7bf06d5 (source and schema:
differentiate with examples, 2015-12-18, #276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
Schema and validator for `config.json`, 2016-01-19, #313).
It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode). The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path"). Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.
Signed-off-by: W. Trevor King <wking@tremily.us>
Through 0bcb7119 (Merge pull request #341 2016-03-10).
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Vincent Batts
Mrunal Patel
W. Trevor King
Michael Crosby
Qiang Huang
Antonio Murdaca
Giuseppe Scrivano
liangchenye
Julian Friedman