Commit 3ee4b06
committed
config-linux: Specify relationships for new namespaces
These were contentious [1,2], so they weren't part of the previous
commit. I still think we want to say something about these
relationships.
For example, if you ask for a new uts namespace but do not set the
optional hostname, having the seed defined means that the hostname in
the container UTS namespace is well-defined (it will be whatever the
hostname was in the runtime UTS namespace).
This is less of an issue for the mount namespace, because with
root.path REQUIRED, there's no way to avoid clobbering whatever mounts
you got from your seed (which makes not asking for a new mount
namespace exciting ;).
We already have some of "runtime namespace" conditions (e.g. when
linux.namespaces[].path is unset), so runtimes should already have
implementation-specific wording around what the runtime namespaces are
(we don't explicitly make them implementation-defined, although we
probably should). Anyhow, that's not a new concept added by this
commit.
If we want to explicitly make the parent / seed implementation-defined
and not tied to the implementation-defined runtime namespaces, I guess
we could do that (by rejecting this commit). But I think "I want this
container to run in a new user/pid namespace that is a child of the
runtime user/pid namespace" should be something that has a portable
config expression. Otherwise it becomes very unclear what to put in
the hostID field for (u|g)idMappings, because you don't know what
namespace will be used to interpret the hostIDs.
[1]: #767 (comment)
[2]: #767 (comment)
Signed-off-by: W. Trevor King <wking@tremily.us>1 parent ae6288a commit 3ee4b06
1 file changed
+3
-0
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
40 | 40 | | |
41 | 41 | | |
42 | 42 | | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
43 | 46 | | |
44 | 47 | | |
45 | 48 | | |
| |||
0 commit comments