config-linux: Specify relationships for new namespaces

[wking]

Spun off from #767, since these are contentious. I still think we want to say something about these relationships.

We already have some of “runtime namespace” conditions (e.g. when a type is not listed in linux.namespaces[]), 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.

Seeded namespaces

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 ;).

Hierarchical namespaces

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.

Namespace ownership

This is another case where I think specified clarity is essential. A new network namespace will not be very useful if you don't know who owns it.

[wking]

This got kicked around some in today's meeting (although my notes are thin). My impression was that there is concern that we are documenting the kernel (which I'm trying to avoid) and that these requirements are somewhat tautological with the source of the unshare(2) or clone(2) being the “runtime namespace” by definition (which I agree with). It's been a while since I looked at the glossary entry, and now that I do I think:

• The current glossary entry makes all namespaces sound hierarchical, when they aren't.
• The current glossary entry has no RFC 2119 language for compliance testing.

I think we want to land something like the wording in this PR (as of c9b6118) with RFC 2119 teeth, and then update the glossary entry to be something like:

On Linux, a the namespace from which the container namespaces [link to config-linux.md#namespaces] are created.

Which embraces the overlap by trimming the incorrect glossary entry and referencing the RFC 2119 teeth here.

I don't think we should leave these relationships alone with an argument like “namespaces can be confusing, so let's not say obvious things like this”. If namespaces are confusing, I think that's a good reason to say obvious things, because “obvious” is in the eye of the beholder. And it's especially good if we can phrase them specifically enough for compliance testing, since that removes the eye-of-the-beholder ambiguity.

[tianon]

I feel like this is already implied (given that it's how the kernel itself works), and that there isn't a lot of value added by explicitly mentioning it or attempting to validate runtime behavior around it.

I'd vote to either close or defer discussion to post-1.0.

[wking]

On Wed, May 10, 2017 at 09:39:10PM -0700, Tianon Gravi wrote: I feel like this is already implied (given that it's how the kernel itself works)…

That's how the kernel works if you're calling unshare(2) or clone(2) from the runtime namespaces to create new container namespaces. But there's nothing in the spec that says you have to do it that way. You could have a namespace-generating process that creates new namespaces and pipes file descriptors for them into the container process on a Unix socket which the container process setns(2)s. That's how the kernel works too, but I doubt it's what most callers will expect.

… and that there isn't a lot of value added by explicitly mentioning it or attempting to validate runtime behavior around it.

If my feeling is that this is a useful addition and yours is “it doesn't add much”, I'd recommend erring on the side of adding three lines to config-linux.md and trimming a line from the glossary (I've included my proposal from [1] in a reroll from c9b6118 → cf8306e). I'm also happy to PR runtime-tools tests if that helps. If there is anything else I can do to reduce the maintenance cost of this change (which I expect to be small), please let me know. [1]: #795 (comment)

[hqhq]

Why not link to the glossary container namespace above? Looks more suitable to me.

[hqhq]

I feel like this is already implied (given that it's how the kernel itself works), and that there isn't a lot of value added by explicitly mentioning it or attempting to validate runtime behavior around it.
I'd vote to either close or defer discussion to post-1.0.

Agreed.

I'd recommend erring on the side of adding three
lines to config-linux.md and trimming a line from the glossary

I'm +1 on this.

[vbatts]

NACK on this language.

[vbatts]

A couple of the clarifying sentences are okay, but the seeding and hierarchical namespace language is too prescriptive and not okay to add. closing. add prs for the simpler sentences if still desired

[wking]

On Wed, May 24, 2017 at 08:55:44AM -0700, v1.0.0.batts wrote: A couple of the clarifying sentences are okay, but the seeding and hierarchical namespace language is too prescriptive and not okay to add. closing.

Without these statements, a config including [1] could lead to a new container PID namespace that is *not* a child of the runtime namespace. With a PID namespace hierarchy like: A |-- B `-- C where B is the runtime PID namespace, the container PID namespace D could be created in any of the following positions: A |-- B |-- C `-- D' A |-- B | `-- D'' `-- C A |-- B `-- C `-- D''' A |-- B `-- C `-- E `-- D''' etc. But I'd like to restrict runtimes to only D''. Do you feel that is too perscriptive? Do you want to allow runtimes to use the D', D''', D''', etc., positions? If so, can you explain why? If not, why allow them?

add prs for the simpler sentences if still desired

I've spun the glossary changes out into #852 and #853.

[cyphar]

Do you want to allow runtimes to use the D', D''',
D''', etc., positions? If so, can you explain why? If not, why allow
them?

If the runtime can implement all of the relevant lifecycle stuff with those semantics, they can go for it. I don't understand why it is a necessity that ps aux in the caller's namespace must container the container PIDs. That's not required anywhere and would actually break any daemon-based container runtimes (at least it would make their jobs harder for no obviously beneficial reason).

Not to mention there might be some very odd usecases where you might actually want the functionality of joining namespaces you couldn't have created.

Without having something as awful as cgroupsPath for namespaces, mandating any rules on this that aren't extensible on this topic will break implementations and make people very unhappy. Please don't make a PR for nsPath, it will be a waste of time to review (such a path doesn't have any kernel parallel and not every hierarchy is a VFS).

[wking]

On Wed, May 24, 2017 at 11:02:24AM -0700, Aleksa Sarai wrote: If the runtime can implement all of the relevant lifecycle stuff with those semantics, they can go for it.

Lifecycle semantics are not the problem, especially if we address #731. If we flip this over to user namespaces (also hierarchical), one problem is “what do I put in hostID?” [1]. If the goal is for the new container namespace to map B's UID 1000 (which happens to be to UID 2000 in A and unmapped in C) to D's PID 0, do I put 1000 in linux.uidMappings.hostID? Do I put 2000 in there? The correct value depends on whether the runtime will create D', D'', D''', etc.

I don't understand why it is a necessity that `ps aux` in the caller's namespace must container the container PIDs. That's not required anywhere and would actually break any daemon-based container runtimes (at least it would make their jobs harder for no obviously beneficial reason).

Perhaps you want the container killed when PID namespace B's init exits. The way to support daemon-based container runtimes is to have those runtimes clearly document their runtime namespace. Calling a ‘create’ action from a shell in namespace B doesn't mean that B is the runtime namespace. The runtime namespace doesn't even have to be on the same host. But whatever the runtime namespace is (which should be implementation-defined), you need the container namespaces to be children/seeded from the runtime namespaces in order to know what to put in linux.uidMappings.hostID and similar or to how to have the runtime create nested PID namespaces. [1]: /~https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/config-linux.md#user-namespace-mappings