config-linux: Specify host mount namespace for namespace paths

[wking]

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. 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.
2. 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.
3. Host process closes unneeded fd 3.
4. Container process joins the user namespace referenced by fd 3.

[crosbymichael]

😞

It is the namespace of the runtime (not host) as you can nest things so this is not exactly correct to say.

[wking]

On Fri, Dec 18, 2015 at 11:02:55AM -0800, Michael Crosby wrote:

-* path (string, optional) - path to namespace file
+* path (string, optional) - path to namespace file in the host mount namespace

😞

It is the namespace of the runtime (not host) as you can nest things
so this is not exactly correct to say.

If we prefer “runtime” to “host” for that distinction, I'm fine
changing that. Ideally we'd land a glossary like #107 so we had a
place to define these terms. For me:

• 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.

@mrunalp used the “host” phrasing in some of the earlier #231 commits
[1,2], but again, if “host” → “runtime” gets me to a consensus naming
scheme, then I'll reroll this commit.

[mrunalp]

I think it is good the way it is. The path to a namespace file is unambiguous :)

[wking]

On Fri, Dec 18, 2015 at 11:28:29AM -0800, Mrunal Patel wrote:

-* path (string, optional) - path to namespace file
+* path (string, optional) - path to namespace file in the host mount namespace

I think it is good the way it is. The path to a namespace file is
unambiguous :)

Is that “we can close this PR” or “we don't need the ‘host’ →
‘runtime’ change 1”?

[mrunalp]

I meant that we can close this PR.

[vbatts]

this seems more like a validation concern to me. i'm not sure what you're technically attempting to achieve here.

[wking]

On Fri, Dec 18, 2015 at 01:48:35PM -0800, Vincent Batts wrote:

-* path (string, optional) - path to namespace file
+* path (string, optional) - path to namespace file in the host mount namespace

this seems more like a validation concern to me.

The spec is a meeting point beween runtime authors, bundle
authors, runtime callers, and validation authors (who are likely both
bundle authors and runtime callers). I don't see how you could have
an ambiguity that only impacted one subset.

i'm not sure what you're technically attempting to achieve here.

I'm just trying to make sure folks don't misinterpret the namespace
path as “in the current mount namespace just before the setns call”,
which is what I did in ccons (and which you want for the alternative
namespace approach in 1). If we all agree that the interpretation
should be “paths are resolved in the mount namespace from which the
runtime is launched”, then landing wording to that effect seems easy
to do, and will either:

a. help reduce ambiguity and resulting conflicts, or
b. not take up too much space

depending on your view of how ambiguous the current wording is.

[philips]

I think "runtime namespace" is the most compact way of expressing this. We can expand that meaning in a glossary.

[wking]

On Tue, Dec 22, 2015 at 10:32:46PM -0800, Brandon Philips wrote:

-* path (string, optional) - path to namespace file
+* path (string, optional) - path to namespace file in the host mount namespace

I think "runtime namespace" is the most compact way of expressing
this. We can expand that meaning in a glossary.

Ok, that makes two votes in favor of “runtime” phrasing 1 after I'd
written up my reasons for preferring host in detail 2. I'll rebase
this PR to use that language and add it to the glossary once something
like #107 lands and we have a glossary.

[wking]

On Wed, Dec 23, 2015 at 09:33:02AM -0800, W. Trevor King wrote:

Ok, that makes two votes in favor of “runtime” phrasing 1 after
I'd written up my reasons for preferring host in detail 2. I'll
rebase this PR to use that language and add it to the glossary once
something like #107 lands and we have a glossary.

Done with f1146ed → 4484bdd.

[mrunalp]

Needs a rebase

[wking]

On Wed, Mar 16, 2016 at 10:39:42AM -0700, Mrunal Patel wrote:

Needs a rebase

Rebased with 4484bdd → 5dad125, with Git resolving any conflicts for
me.

[crosbymichael]

LGTM

[mrunalp]

LGTM