Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
config-linux: Clearer punt to kernel for linux.devices
This is a bit awkward, since: * It's not a direct wrapper around mknod(2) (which, for example, does not use the c/b/u/p characters). * The runtime doesn't have to use mknod, so binding it to mknod(1)-ish invocations doesn't make much sense. Instead, I've bound it to POSIX's stat(3) to show what compliance testing (and anything else inside the container) can expect the results (however the runtime accomplishes them) to look like. The previous wording wasn't clear on whether symlinks were an allowed approach. The new wording explicitly allows them by using stat(1)-like symlink resolution. I've also clarified relative 'path' handling and explicitly declared the appropriate mount namespace (impacts 'path') and PID namespace (impacts 'uid' and 'gid'). Because we're focused on post-create stat calls, I've also added new wording about handling duplicate 'path' values. I've used POSIX reference where possible (vs. Linux man pages), because they contain sufficient detail for this section, have well-versioned URLs, and are more likely to be portable if this section ever applies to non-Linux configs (BSD? Solaris?). Related to recent discussion around punting to the kernel [1,2], although in this case we're not changing the JSON Schema because the existing local validation (valid 'type' characters and the 'fileMode' range) both feed into a single mode_t integer in the stat(3) and mknod(2) APIs. For a cleaner kernel punt, we could drop 'type', lift the range limit on 'fileMode', and map it directly to st.st_mode. But that seemed like a big backwards-compat shift for this commit. [1]: opencontainers#780 [2]: opencontainers#690 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
- Loading branch information