On Fri, 28 Jun 2019 at 00:40, Andy Lutomirski <luto@xxxxxxxxxx> 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
