config: strengthen punt to kernel for valid "capabilities" strings#790
Merged
mrunalp merged 1 commit intoopencontainers:masterfrom May 10, 2017
Merged
Conversation
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Member
Author
wking
reviewed
May 9, 2017
| * **`args`** (array of strings, REQUIRED) with similar semantics to [IEEE Std 1003.1-2001 `execvp`'s *argv*][ieee-1003.1-2001-xsh-exec]. | ||
| This specification extends the IEEE standard in that at least one entry is REQUIRED, and that entry is used with the same semantics as `execvp`'s *file*. | ||
| * **`capabilities`** (object, OPTIONAL) is an object containing arrays that specifies the sets of capabilities for the process(es) inside the container. Valid values are platform-specific. For example, valid values for Linux are defined in the [capabilities(7)][capabilities.7] man page. | ||
| * **`capabilities`** (object, OPTIONAL) is an object containing arrays that specifies the sets of capabilities for the process(es) inside the container. Valid values are platform-specific. For example, valid values for Linux are defined in the [capabilities(7)][capabilities.7] man page, such as `CAP_CHOWN`. Any value which cannot be mapped to a relevant kernel interface MUST cause an error. |
Contributor
There was a problem hiding this comment.
If we're looking for a clear way to specify the “relevant kernel interface”, cap_from_text(3) is part of the withdrawn POSIX.1e draft specification (and therefore has some chance of being cross-platform) and is supported by libcap. Without clarification, I'd expect the kernel intefaces to be capset(2) and/or prctl(2), but both of those happen after the capabilities have been converted to integers.
Member
|
LGTM |
1 similar comment
Contributor
|
LGTM |
Merged
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
4 participants
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.
Opening this as we discussed on our review call today. The intent here is to not have an explicit list of "string to kernel constant" mappings in the specification, and to instead expect implementations to make a reasonable effort to have up-to-date mappings (especially for kernel features that might be newer than the particular specification release), and to error out for anything that they can't map.
As I mentioned on the call, I do not feel that this is a "1.0 blocker" -- the existing language is sufficient in my eyes to get the point across to implementors what they're expected to do.