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

linux: relax filesystem requirements for container #666

Merged
merged 1 commit into from
Feb 3, 2017

Conversation

dqminh
Copy link
Contributor

@dqminh dqminh commented Jan 23, 2017

change MUST to SHOULD so containers are not required to have all these filesystems mounted.

Related to discussions in opencontainers/runc#1176

cc @cyphar @crosbymichael @philips @justincormack

change MUST to SHOULD so containers are not required to have all these
filesystems mounted.

Signed-off-by: Daniel Dao <dqminh89@gmail.com>
@justincormack
Copy link
Contributor

justincormack commented Jan 23, 2017

I believe /proc MUST still be supplied, and /dev/pts in the case where you specify a console, ~~~and /sys if you specify sysctl config~~~. Also /dev seems curiously missing...

@wking
Copy link
Contributor

wking commented Jan 23, 2017 via email

@dqminh
Copy link
Contributor Author

dqminh commented Jan 23, 2017

I believe /proc MUST still be supplied, and /dev/pts in the case where you specify a console, and /sys if you specify sysctl config.

Makes sense. WDYT about:

  • /proc must be mounted
  • /sys must be mounted if sysfs config is set
  • /dev/pts must be available if terminal= true ( dont we want to take it out of process, i dont quite remember ?? )
  • leave out /dev/shm and the rest. I dont actually had any special requirements to not have /dev/shm, but i also feel like you use shm do you need /dev/shm. runc is a low level tool and should allow for weird use cases. In particular if you want to totally lock down ability to write to files by having no writeable mounts you want to remove /dev/shm makes sense

@justincormack
Copy link
Contributor

@wking /dev/shm is writeable (if it is not writeable it cannot be used for shm), and therefore can be used to fill a chunk of memory, possibly enough to cause your actual processes to crash if an attacker found a way to write to it. Without this you can have a totally read only container. So I think it is worthwhile to be able to remove it.

@wking
Copy link
Contributor

wking commented Jan 23, 2017 via email

@Kxuan
Copy link

Kxuan commented Jan 24, 2017

/sys must be mounted if sysfs config is set

sysctl writes value to /proc/sys, not /sys. so it is not needed to mount sysfs to /sys.

@gregkh
Copy link
Member

gregkh commented Jan 24, 2017

@Kxuan sysctl is not sysfs, please don't get those confused. sysfs should be mounted at /sys, if the container needs it. Depends on what is running in it.

@Kxuan
Copy link

Kxuan commented Jan 25, 2017

@gregkh yes, I know it. but they are discussing about "/sys if you specify sysctl config."

@crosbymichael
Copy link
Member

crosbymichael commented Feb 2, 2017

LGTM

The spec does not specify what you MUST populate in your own spec. If I'm writing a spec I can add whatever I want in it. This section is meant as a hint to spec authors that these filesystems should be made available.

We need to stick to specing the schema for the fields in the spec and not spec what users put in it.

Approved with PullApprove

@wking
Copy link
Contributor

wking commented Feb 2, 2017

This section is meant as a hint to spec authors that these filesystems should be made available.

With the phrasing in 279c3c0, it looks like we're going from “the runtime MUST supply these even if the config doesn't call for them in mounts” to “the runtime SHOULD supply these even if the config doesn't call for them in mounts” (and I don't think we want that). If the intention is actually to go to “config authors probably want to include mounts entries for these”, then I think we need to make that more explicit. Something like:

On Linux, configuration authors are likely to want mounts to contain some of the following:

[entries from opencontainers/runtime-tools#24]

@mrunalp
Copy link
Contributor

mrunalp commented Feb 3, 2017

LGTM

Approved with PullApprove

@mrunalp mrunalp merged commit 7278567 into opencontainers:master Feb 3, 2017
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Feb 3, 2017
The MUST default-filesystem wording altered in 279c3c0 (linux: relax
filesystem requirements for container, 2017-01-23, opencontainers#666) had read (to
me, anyway) as:

  The runtime MUST supply these even if the config doesn't call for
  them in mounts.

with 279c3c0 weaking it to:

  The runtime SHOULD supply these even if the config doesn't call for
  them in mounts.

But that's not very useful (callers that *need* a given mount will
still have to configure it explicitly).  However, one interpretation
of the 279c3c0 wording seems to be something like [1]:

  Config authors probably want to include mounts entries for these.

That's fine, and this commit tries to make that interpretation more
obvious by shifting the config recommendation over to the Linux
'mounts' example.

[1]: opencontainers#666 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Feb 3, 2017
The MUST default-filesystem wording altered in 279c3c0 (linux: relax
filesystem requirements for container, 2017-01-23, opencontainers#666) had read (to
me, anyway) as:

  The runtime MUST supply these even if the config doesn't call for
  them in mounts.

with 279c3c0 weaking it to:

  The runtime SHOULD supply these even if the config doesn't call for
  them in mounts.

But that's not very useful (callers that *need* a given mount will
still have to configure it explicitly).  However, one interpretation
of the 279c3c0 wording seems to be something like [1]:

  Config authors probably want to include mounts entries for these.

That's fine, and this commit tries to make that interpretation more
obvious by shifting the config recommendation over to the Linux
'mounts' example.

The values I'm using are straight from [2].

[1]: opencontainers#666 (comment)
[2]: opencontainers/runtime-tools#24

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Mar 16, 2017
Since 279c3c0 (linux: relax filesystem requirements for container,
2017-01-23, opencontainers#666) it's no longer garunteed that /proc will exist.  And
there doesn't seem to be much point in requiring symlinks which will
be known broken.

This commit also tightens the timing.  Before it was just "after the
container has `/proc` mounted", which could have happened during the
'delete' operation (if the container authors wanted to be especially
ornery).  With this commit, I've put the creation in step 2 of the
lifecycle.  And within step 2, it happens after 'mounts' has been
processed.

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Mar 16, 2017
Since 279c3c0 (linux: relax filesystem requirements for container,
2017-01-23, opencontainers#666) it's no longer guaranteed that /proc will exist.
And there doesn't seem to be much point in requiring symlinks which
will be known broken.

This commit also tightens the timing.  Before it was just "after the
container has `/proc` mounted", which could have happened during the
'delete' operation (if the container authors wanted to be especially
ornery).  With this commit, I've put the creation in step 2 of the
lifecycle.  And within step 2, it happens after 'mounts' has been
processed.

Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/nmbug-oci that referenced this pull request Jul 26, 2017
The mount-requirement was softened to a SHOULD in [1].  It's not clear
to me whether that SHOULD is directed at config authors ("you should
explicitly include mounts for these") or at runtimes ("you should
provide these even if the config doesn't ask for them"), but my
attempts to clarify that one way or the other were both rejected
[2,3].  The current runtime-tools and runC approach favors the
config-author direction [4], which is what I'd asked for in the
original thread post, so I'm tagging this obsolete.

[1]: opencontainers/runtime-spec#666
[2]: opencontainers/runtime-spec#679 (comment)
[3]: opencontainers/runtime-spec#678 (comment)
[4]: opencontainers/runtime-tools#24
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

Successfully merging this pull request may close these issues.

7 participants