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

config: strengthen punt to kernel for valid "capabilities" strings #790

Merged
merged 1 commit into from
May 10, 2017

Conversation

tianon
Copy link
Member

@tianon tianon commented May 9, 2017

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.

Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
@tianon
Copy link
Member Author

tianon commented May 9, 2017

This is related to #755 and #766 (which should probably be re-opened, since CAP_ isn't actually prescribed by the specification -- we're punting to the kernel and the runtime implementation to do best-effort and the Linux kernel just happens to include CAP_ for all current valid values).

@@ -132,7 +132,7 @@ For Windows, see [mountvol][mountvol] and [SetVolumeMountPoint][set-volume-mount
* **`env`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001's `environ`][ieee-1003.1-2001-xbd-c8.1].
* **`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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@crosbymichael
Copy link
Member

crosbymichael commented May 9, 2017

LGTM

Approved with PullApprove

1 similar comment
@mrunalp
Copy link
Contributor

mrunalp commented May 10, 2017

LGTM

Approved with PullApprove

@mrunalp mrunalp merged commit aa1631c into opencontainers:master May 10, 2017
@tianon tianon deleted the punt-caps-to-kernel-docs branch May 10, 2017 21:00
@vbatts vbatts mentioned this pull request Jul 5, 2017
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.

4 participants