[bug] capability: some errors related to pid

[lifubang]

As capability package can be used to set other process's cap, but unfortunately except these two type caps:

1. Bounding cap: we can only drop capabilities from the bounding set via prctl(PR_CAPBSET_DROP), but this operation is only used for current process;
2. Ambient cap: we can only modify ambient cap set via prctl(PR_CAP_AMBIENT), but this operation is also only used for current process.

So if we use capability package for other process via NewPid(pid>0), when we want to use Apply to modify target process's bounding and ambient cap set, it will modify current process's bouding and ambient cap set, rather than the target process.

The original post is here: #165 (comment)

[kolyshkin]

Let me quote my original comment as it better explains the issue.

I just realized this package API is flawed. You start with NewPid2(pid), but then some capabilities can only be applied to current process (when pid == 0 or pid == gettid()`). Meaning, if you do something like this:

c, err := capability.NewPid(somePid)
...
c.Set(capability.AMBIENT, capability.CAP_CHOWN)
c.Apply(capability.AMBIENT)

The ambient capability will be applied to the current process, rather than the process identified by somePid.

But there's more!!

Using capset(2) to set P/E/I caps for other process is not permitted either. From capset(2) man page:

EPERM The caller attempted to use capset() to modify the capabilities of a thread other than itself, but lacked sufficient privilege. For kernels supporting VFS capabilities, this is never permitted.

Here "kernels supporting VFS capabilities" means some kernels >= v2.6.24, and all kernels >= 2.6.33.

Since Go 1.18+ only supports Linux >= 2.6.32, this pretty much means "all kernels".

So, we should reject non-zero pid much earlier.