Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host system bundles #332

Closed
huntc opened this issue Mar 7, 2016 · 7 comments
Closed

Host system bundles #332

huntc opened this issue Mar 7, 2016 · 7 comments

Comments

@huntc
Copy link

huntc commented Mar 7, 2016

In addition to file system bundles, does the spec deem it permissible to ship only a config.json and have the root.path assume that it will be "provided". I'm thinking of using config.json in a way that it can assume a rootfs being provided by the host OS. My goal is so that I can control the underlying file system of all containers, which will then facilitate patching in the case of security vulnerabilities.

Could such a scenario be introduced as a "host system bundle" perhaps? I'd be happy to contribute the beginnings of its spec if it were deemed as being useful.

Thoughts?

@vbatts
Copy link
Member

vbatts commented Mar 7, 2016

this topic has come up. Even then, the root.path would be /, so, it would not be a subdirectory.
This is generally not advisable. There are /var, /run and other state that could collide. While some of these can be manipulated with mounts and namespaces, but several container runtimes already prohibit running containers against the host's /.

@huntc
Copy link
Author

huntc commented Mar 7, 2016

I believe a rootfs should still be supplied for these host system bundles - it is just that the host supplies it and not the bundle. Make sense? The goal is for many containers to share the same rootfs at runtime, but not to share the hosts FS directly.

@wking
Copy link
Contributor

wking commented Mar 7, 2016

On Mon, Mar 07, 2016 at 07:05:34AM -0800, Vincent Batts wrote:

this topic has come up.

Linking into past discussions, see [1,2].

 Subject: Dropping the rootfs requirement and restoring arbitrary bundle content
 Date: Wed, 26 Aug 2015 12:54:47 -0700
 Message-ID: <[email protected]>

@huntc
Copy link
Author

huntc commented Mar 7, 2016

Thanks for the refs. I shall read them today. Any chance you can summarise them here?

@wking
Copy link
Contributor

wking commented Mar 7, 2016

On Mon, Mar 07, 2016 at 01:38:47PM -0800, Christopher Hunt wrote:

Thanks for the refs. I shall read them today. Any chance you can
summarise them here?

I think discussions like this are supposed to happen on the list 1,
and the initial post in 2 still summarizes my current views pretty
well (although it has some stale references to runtime.json, removed
in #284). The pushback mostly seems to revolve around “why would you
need that?” [3,4]. But since it's easy to support (just don't pivot
root), I'd rather support it and let folks make their own policy
decisions about whether they'll run bundles that don't declare a local
root.path 5.

 Subject: Dropping the rootfs requirement and restoring arbitrary bundle content
 Date: Wed, 26 Aug 2015 12:54:47 -0700
 Message-ID: <[email protected]>

@huntc
Copy link
Author

huntc commented Mar 7, 2016

Apologies. I shall continue the discussion on the list. The OCI website didn't make it obvious that there was a list hence my raising of the issue here.

@huntc huntc closed this as completed Mar 7, 2016
@wking
Copy link
Contributor

wking commented Mar 7, 2016

On Mon, Mar 07, 2016 at 03:36:40PM -0800, Christopher Hunt wrote:

Apologies. I shall continue the discussion on the list.

No need to apologize, especially to me since I'm not a maintainer ;).
I was just pointing out the documented list preference as a
suggestion, but it's possible that the maintainers would prefer this
particular issue be discussed here (in which case I think we should
close out the list thread with a link to this issue). So I don't
really care where the discussion happens, but I'd prefer it happen in
one place ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants