Masked paths setting in the container

[mrunalp]

This allows one to hide files such as /proc/kcore from the container process.

Signed-off-by: Mrunal Patel mrunalp@gmail.com

[mrunalp]

@crosbymichael @LK4D4 PTAL

[wking]

On Mon, Sep 14, 2015 at 02:25:03PM -0700, Mrunal Patel wrote:

This allows one to hide files such as /proc/kcore from the container process.

Why not just have this in config.md:

"mounts": [
{"name": "null", "path": "/proc/kcore"},
…
],

And this in runtime.md:

"mounts": {
"null": {
"type": "bind",
"source": "/dev/null"
},
…
}

? That way there's nothing to implement, and it doesn't seem like
that much of a setup cost for the bundle author.

[mrunalp]

@wking Agree, but the idea is simplifying the config for some common cases/scenarios. If we agree it is not worth it I will close this :)

[wking]

On Wed, Sep 16, 2015 at 08:06:19AM -0700, Mrunal Patel wrote:

@wking Agree, but the idea is simplifying the config for some common
cases/scenarios. If we agree it is not worth it I will close this :)

Fair. Some things to balance when deciding on whether adding
something simplifies things or not:

a. Does it make it easier to write the config for a particular use
case?
b. Does the additional complication make the spec harder to
understand?

Any pure addition is likely to do both, although refactoring things
might make use cases easier and simplify the spec.

Perhaps we can mitigate (b) here by shifting syntactic sugar like this
PR (where the same effect could be achieved by more primitive/generic
config entries) off into its own section. That way folks could read
through the core section more quickly, and only dip into these
shortcut options if/when they feel like they want something more
convenient.

And to make life easier for implementors, it might be worth writing a
generic preprocessor that unwinds the syntactic sugar into the more
primitive/generic constructs? That would also make it easier to tell
how the sugar fits in (e.g. presumably the maskedPaths mounts are made
after we've finished setting up the generic mounts, but that's not
explicitily stated in this PR as of 8d705eb).

[vbatts]

perhaps that mount approach is an implementation approach, but not the requirement?
If some runtime, cow fs, or future kernel feature allowed the filepath to just not exist, then those could be allowable as well. Not just an exclusive bitbucket.

[wking]

On Fri, Sep 25, 2015 at 11:17:19AM -0700, Vincent Batts wrote:

+Masked paths allow hiding paths in the container by bind mounting
/dev/null over them to prevent access by the container process.

perhaps that mount approach is an implementation approach, but not
the requirement? If some … cow fs … feature allowed the filepath to
just not exist…

What would this look like? Looking for similar tech besides “bind
over it”, there's the device cgroups 1. But there the access is
bound to major/minor, and not by path. That's not a big deal though,
I could see something like that bound by path. But the cgroup
approach gives errors like:

cgcreate -g devices:/device-group

cgset -r devices.deny='c 1:3 mrw' device-group

cgexec -g devices:/device-group cat /dev/null

cat: /dev/null: Operation not permitted

cgdelete -g devices:/device-group

and not just an empty read. So I'd be cautious about saying “don't
worry about how it's implemented, just use this to block access”.

[vbatts]

I like the idea, just need to open up the verbiage.

[mrunalp]

I am closing this for now. We could use the existing facilities to achieve this.