Unhelpful error message when attempting to unset Permitted capabilities

[JarredAllen]

If you attempt to set capabilities in the Permitted capabilities set to a strict subset of the current capabilities without first dropping them in the Effective set, then this library returns an unhelpful error message CapsError("capset failure: Operation not permitted (os error 1)").

Under the hood, this library sets exactly what you tell it to and otherwise preserves the current state. This causes issues when using set to drop a lot of capabilities at once (for my application, I only need a few capabilities, so it's easier to set what I need than to clear what I don't). If I immediately set the Permitted capabilities, then the syscall it produces tries to preserve the current Effective capabilities and set the Permitted capabilities, which produces an Effective set that is no longer a subset of the Permitted set (which isn't allowed, hence the error return).

I'd prefer if calling set on the Permitted capabilities could also intersect the provided capabilities with the current Effective set and only set those Effective capabilities, so you can just make one call to set to drop the capabilities. However, that would be changing the API in ways that I'm not sure if you'd want, so if that's not allowed, then I'd prefer for this failure mode to get a more descriptive error message (likely has to be manually inserted as a check before we syscall into the kernel) and for documentation of this limitation could be put into set (and other methods if they also have this behavior).

[lucab]

Thanks for the report.
Unfortunately the errors returned from the kernel are often a bit cryptic, and there isn't much we can do about that.
I guess we can slightly reword the error message to be more explicit (like syscall 'capset' failed: ...), but for example you'd still need to consult https://man7.org/linux/man-pages/man2/capset.2.html#ERRORS to decode the meaning of the EPERM you got.

I'm not planning to add additional heuristic and smartness to the methods here, as it can be surprising in other ways and even harder to discover.

If there are very common usecases, we can consider adding ad-hoc functions under a new dedicated caps::helpers module, but so far it has not been the case.