config-linux: Many config properties without RFC 2119 language #746
Comments
wking
changed the title
|
#728 is another PR that is partially addressing this. |
|
In the meeting today, folks were asking for a way to close this issue, so here's a checklist of all the properties in config-linux for whether or not they have sufficient runtime-facing RFC 2119 language for compliance testing (as of 138ad89):
Ideally we'd close each of these with a compliance test in runtime-tools, but I'm currently checking them off when I feel like there is sufficient spec clarity, regardless of the existence of compliance tests. If folks feel like I should be checking something off that is unchecked, landing runtime-tools compliance tests (or pointing out the existing runtime-tools tests which I've overlooked) would be a convincing way to argue for checking the property off. In some cases (e.g. I'll come back and update this comment as work continues. |
This was referenced May 8, 2017
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this issue
May 19, 2017
Since ce55de2 (Remove range limit which depend on kernel, 2017-04-26, opencontainers#780), the spec has been more aggressively punting to the kernel APIs (vs. carrying local versions of kernel limitations). For the properties touched by this commit, a pull request to reflect our old valid values (e.g. requiring 'type' to match ^[acb]$) was rejected as part of this punting approach. However, before this commit, it wasn't clear exactly what kernel interface was being punted to. With this commit, we replace the old inline docs with an explicit punt to the device whitelist controller, listing the exact actions that the runtime MUST take for given config values. This allows for compliance-testing runtimes [2] (ensuring config portability between compliant runtimes) and makes it possible to validate a given config against a given kernel (e.g. Linux 4.11.1 only accepts 'a', 'b', and 'c' as type characters [3]). [1]: opencontainers#690 (comment) [2]: opencontainers#746 [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/security/device_cgroup.c?h=v4.11.1#n618 Signed-off-by: W. Trevor King <wking@tremily.us>
This was referenced May 19, 2017
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this issue
Jun 1, 2017
Since ce55de2 (Remove range limit which depend on kernel, 2017-04-26, opencontainers#780), the spec has been more aggressively punting to the kernel APIs (vs. carrying local versions of kernel limitations). For the properties touched by this commit, a pull request to reflect our old valid values (e.g. requiring 'type' to match ^[acb]$) was rejected as part of this punting approach. However, before this commit, it wasn't clear exactly what kernel interface was being punted to. With this commit, we replace the old inline docs with an explicit punt to the device whitelist controller, listing the exact actions that the runtime MUST take for given config values. This allows for compliance-testing runtimes [2] (ensuring config portability between compliant runtimes) and makes it possible to validate a given config against a given kernel (e.g. Linux 4.11.1 only accepts 'a', 'b', and 'c' as type characters [3]). [1]: opencontainers#690 (comment) [2]: opencontainers#746 [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/security/device_cgroup.c?h=v4.11.1#n618 Signed-off-by: W. Trevor King <wking@tremily.us>
|
We don't want to go down this route. The actually changes that were submitted are coupling the spec to very, very implementation specific functionality of kernels, versions, and posix specs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've filed #745 to add RFC 2119 language to
disableOOMKiller, but there are many other settings inconfig-linux.mdwithout RFC 2119 wording to connect them with compliance testing (e.g.oomScoreAdj,memory, …). Without RFC 2119 language, it is not very clear what config-author and runtime responsibilities are intended to be. And it is clear that, whatever the intentions were:"oomScoreAdj" = 999999999999999999999999999999999999999999999999999999999999999999).I think we should address this before cutting 1.0. #745 is a (small) step in that direction, but I wanted to open this issue to get feedback on the issue in general (without getting bogged down on a specific setting).
The text was updated successfully, but these errors were encountered: