WIP: libcontainer/specconv/spec_linux: defaults should not be a no-op#1444
Closed
wking wants to merge 1 commit intoopencontainers:masterfrom
Closed
WIP: libcontainer/specconv/spec_linux: defaults should not be a no-op#1444wking wants to merge 1 commit intoopencontainers:masterfrom
wking wants to merge 1 commit intoopencontainers:masterfrom
Conversation
wking
force-pushed
the
defaults-mount-option
branch
2 times, most recently
from
435b0c7 to
a6c4f38
Compare
It has been since it landed in 9fac183 (Initial commit of runc binary, 2015-06-21), but the spec currently references mount(8) for these options [1] and mount(8) has: defaults Use the default options: rw, suid, dev, exec, auto, nouser, and async. Note that the real set of all default mount options depends on kernel and filesystem type. See the beginning of this section for more details. I exepect that "real set" paragraph applies to: Note that filesystems also have per-filesystem specific default mount options (see for example tune2fs -l output for extN filesystems). This commit sets up 'defaults' according to that option list, but does not do anything about 'auto' or 'nouser', which do not map to MS_* flags and only apply to fstab entries. For what its worth, util-linux 2.28.2 seems to ignore 'defaults' instead of clearing bits: # strace -o /tmp/trace mount -t tmpfs -o ro,defaults - /tmp/a # grep 'mount(' /tmp/trace mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL|MS_RDONLY, NULL) = 0 While a single-bit clear option does unset an earlier bit: # strace -o /tmp/trace mount -t tmpfs -o ro,rw - /tmp/a # grep 'mount(' /tmp/trace mount("-", "/tmp/a", "tmpfs", MS_MGC_VAL, NULL) = 0 but the spec is currnently punting to the util-linux mount(8) page and not to the util-linux implementation. [1]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc5/config.md#L68 [2]: http://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-INDEPENDENT_MOUNT%20OPTIONS Signed-off-by: W. Trevor King <wking@tremily.us>
wking
force-pushed
the
defaults-mount-option
branch
from
a6c4f38 to
4999aba
Compare
wking
changed the title
Contributor
Author
|
I've posted a request for clarification to the util-linux list to resolve the differences between my reading of the man page and the util-linux implementation. |
Contributor
Author
|
Updated mount(8) wording is still up in the air, but Karel Zak confirmed that runC's current |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It has been since it landed in 9fac183, but the spec currently references mount(8) for these options and mount(8) has:
I exepect that “real set” paragraph applies to:
For what its worth, util-linux 2.28.2 seems to ignore
defaultsinstead of clearing bits:While a single-bit clear option does unset an earlier bit:
but the spec is currnently punting to the util-linux mount(8) page and not to the util-linux implementation.
Related to opencontainers/runtime-spec#771.