On Fri, 28 Jun 2019 at 00:40, Andy Lutomirski [off-list ref] wrote:

I have a bigger issue with this patch, though: it's a really awkward way
to pretend to have capabilities.  For bpf, it seems like you could make
this be a *real* capability without too much pain since there's only one
syscall there.  Just find a way to pass an fd to /dev/bpf into the
syscall.  If this means you need a new bpf_with_cap() syscall that takes
an extra argument, so be it.  The old bpf() syscall can just translate
to bpf_with_cap(..., -1).

I agree, this seems nicer from my POV, since it evades the issues with
the Go runtime I pointed out in the other message.

It also seems like this wouldn't have to create API churn in libbpf? We can
"feature detect" the presence of the new syscall and use that instead. If
you want you can even keep the semantics of having a "global" credential.

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com