Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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]: opencontainers#767 (comment) [2]: opencontainers#767 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
- Loading branch information