*: remove RHEL6 hack and loosen capability validation

[cyphar]

The RHEL6 hack for CAP_LAST_CAP was causing us some annoyances, with the inter-dependency of generate and validate only existing because of CapValid (which then resulted in a bunch of build-time dependencies that were never used by projects that vendored us).

To fix this issue, drop CapValid entirely so we don't have to touch it anymore -- just assume that CAP_LAST_CAP works on all systems. And in the case of validation we match new changes in the spec where capabilities are now just plain strings (but for the HostSpecific case we still do validation).

Fixes: 1a899a6d893e ("validate: optimize capabilites check") Signed-off-by: Aleksa Sarai [email protected]

[Mashimiao]

I have moved them into common util package in #344

[cyphar]

@Mashimiao Do you want to rebase that PR? In addition, this PR also removes the "validity" checks from generate because generate really shouldn't be checking the validity of it's arguments.

[wking]

On Tue, Apr 11, 2017 at 07:09:55AM -0700, Aleksa Sarai wrote:

In addition, this PR also removes the "validity" checks from generate because generate really shouldn't be checking the validity of it's arguments.

Why not? If you do:

$ oci-runtime-tool generate --cap-add does-not-exist capability DOES-NOT-EXIST must start with CAP_

I think the error message is helpful. And in the more-specific case:

$ oci-runtime-tool generate --cap-add cap_does_not_exist Invalid capability: CAP_DOES_NOT_EXIST

I think the error message is still helpful. You only get the host-specific validation if you explicitly ask for it:

$ oci-runtime-tool --host-specific generate --cap-add cap_audit_read …success, because my host has CAP_AUDIT_READ…

So what is the use-case for “I want to set a known-invalid capability”?

[cyphar]

@wking

So what is the use-case for “I want to set a known-invalid capability”?

As far as I'm aware the spec doesn't disallow you from defining your own "capabilities" that are not Linux capabilities. I could imagine that some cloud provider might require "capabilities" in order for you to access certain files or resources.

Sure, there's no reason that we must not check the validity of arguments we are provided, but the reason why generate is separate from validate is so that generation of a config is not conflated with its validation. At least, as a user that's what I would expect.

[wking]

On Tue, Apr 11, 2017 at 10:08:29AM -0700, Aleksa Sarai wrote:

So what is the use-case for “I want to set a known-invalid capability”?

As far as I'm aware the spec doesn't disallow you from defining your own "capabilities" that are not Linux capabilities.

I agree that the spec is weak on this point 1. I think the… uh… “right” approach to that is to completely drop capability value validation, and I've filed opencontainers/runtime-spec#766 as part of that. But keeping these checks in validation and only removing them from generation does not seem like a consistent position. Either we can validate the cap values (in which case I think we want to validate them in both places) or we can't (in which case I think we want to validate them in neither place).

[cyphar]

Since opencontainers/runtime-spec#766 was merged, now the strings are completely arbitrary and there's no need to do any validation. I'll rebase and remove validCap entirely then. I still feel that you could argue having an explicit "please tell me if I'm doing something wrong" validation is different from having an implicit "just add this value and don't ask too many questions" validation -- and so having different behaviour is justified. But I don't mind dropping it from both.