config-linux: Clearer punt to kernel for linux.devices

[wking]

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(2), 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 #690, #780 and punting to the kernel, 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 PR.

[vbatts]

Adding this to the label for a next release. If you feel particular for 1.0.0, state so.

[wking]

On Wed, May 24, 2017 at 08:44:30AM -0700, v1.0.0.batts wrote: If you feel particular for 1.0.0, state so.

Without this PR, there are no runtime-oriented MUST-level requirements for linux.devices. A runtime can ignore linux.devices and still be compliant. More on this issue in #746. So if we punt this to post-1.0, we will certify those runtimes as “1.0 compliant” if anyone submits them for certification.

[wking]

Rebased around #846 with 89b13e5 → b486f4b.

[crosbymichael]

We don't want to bind the spec to kernel headers and specific implementations.

[wking]

We don't want to bind the spec to kernel headers and specific implementations.

This was not binding the spec to kernel headers, it was binding it to headers defined by POSIX. See also “I've used POSIX reference where possible…” in the topic post for this PR.

The only non-POSIX portion of this PR is major(3) and minor(3), because major/minor numbers are not a POSIX concept. For example, pax has to use the very weak:

In this case the devmajor and devminor fields shall contain information defining the device, the format of which is unspecified by this volume of POSIX.1-2008. Implementations may map the device specifications to their own local specification or may ignore the entry.

So the only way to access those major/minor numbers is through some Linux-specific interface like major(3)/minor(3) or bit-shifting (like runtime-tools does).