Linux capabilities not listed

[justincormack]

The Linux capabilities supported are not listed in the spec, but as they are strings and not numbers they probably ought to be, with the spec changed as more are added. If they were numbers it would seem ok, as you could just pass a new number for a new cap, but with strings, each implementation needs to add support to convert the string to a number so it seems sane to have them explicitly listed and a minor version spec bump should another be added (a rare event).

[vbatts]

fair. this is one of those rabbit-holes of effectively specifying the linux kernel API. Thoughts on how to make this age well?

[cyphar]

@justincormack But the kill operation requires specifying a signal (which is a string) but we don't really provide any strong requirements what the strings mean. Should we also specify signal names as well (I'm just wondering which side of the consistency fence we want to land on)?

[wking]

On Wed, Apr 05, 2017 at 03:01:41AM -0700, Justin Cormack wrote: The Linux capabilities supported are not listed in the spec, but as they are strings and not numbers they probably ought to be, with the spec changed as more are added.

My preferred way to do this would be to reference a tagged release of the man-pages listing (e.g. [1]). But inlining them all would be acceptable too. However, in the past there has been resistance to requiring support for particular values (see [2] and later). [1]: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/capabilities.7?h=man-pages-4.10 [2]: #673 (comment)

[justincormack]

Yeah, not entirely sure, I just noticed this when I was thinking where is the list of all caps I can get from the spec. Its all because of C's use of macros deep down. I am fine with us deciding to just put some wording instead of the list, but thought I would bring it up for discussion. It is a question of whether there is an explicit spec version that supports CAP_SYS_FOO or some implementations do and some dont, and you cant work it out from the spec version that you specify.

Currently we do specify the list of namespace kinds (which seems reasonable as they need special handling), and the list of seccomp architectures (kind of weird), and seccomp actions (less weird).

[justincormack]

@wking the man pages are a poor source, they are often outdated. Better to link to the kernel source.

[justincormack]

hmm, the comment in #673 covers much of the same ground, with no real conclusion. So going to close this on the grounds that its already discussed ;)

[vbatts]

it's a tough one, that usually results in vague abstractions. :-\

…

On Wed, Apr 5, 2017 at 10:42 AM Justin Cormack ***@***.***> wrote: hmm, the comment in #673 <#673> covers much of the same ground, with no real conclusion. So going to close this on the grounds that its already discussed ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#755 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF6T08DyHBZ24y-6ahiTqHG-9Im70Fks5rs6hbgaJpZM4M0BJh> .