[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACAyw9-AXy9UFdGkDaaNxw9T8meB+NAH5Yp_0G3nuw1AN5impQ@mail.gmail.com>
Date: Fri, 28 Jun 2019 10:05:56 +0100
From: Lorenz Bauer <lmb@...udflare.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: Song Liu <songliubraving@...com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Kernel Team <kernel-team@...com>, Jann Horn <jannh@...gle.com>,
gregkh@...uxfoundation.org, linux-abi@...r.kernel.org,
kees@...omium.org
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
On Fri, 28 Jun 2019 at 00:40, Andy Lutomirski <luto@...nel.org> 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
Powered by blists - more mailing lists