Thread (21 messages) 21 messages, 5 authors, 2020-05-12

Re: [PATCH v5 bpf-next 0/3] Introduce CAP_BPF

From: Alexei Starovoitov <hidden>
Date: 2020-05-08 23:00:49
Also in: bpf, netdev

On Fri, May 08, 2020 at 03:45:36PM -0700, Casey Schaufler wrote:
On 5/8/2020 2:53 PM, Alexei Starovoitov wrote:
quoted
From: Alexei Starovoitov <ast@kernel.org>

v4->v5:

Split BPF operations that are allowed under CAP_SYS_ADMIN into combination of
CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN and keep some of them under CAP_SYS_ADMIN.

The user process has to have
- CAP_BPF and CAP_PERFMON to load tracing programs.
- CAP_BPF and CAP_NET_ADMIN to load networking programs.
(or CAP_SYS_ADMIN for backward compatibility).
Is there a case where CAP_BPF is useful in the absence of other capabilities?
I generally object to new capabilities in cases where existing capabilities
are already required.
You mean beyond what is written about CAP_BPF in include/uapi/linux/capability.h in patch 1?
There are prog types that are neither tracing nor networking.
Like LIRC2 and cgroup-device are not, but they were put under CAP_SYS_ADMIN + CAP_NET_ADMIN
because there was no CAP_BPF. This patch keeps them under CAP_BPF + CAP_NET_ADMIN for now.
May be that can be relaxed later. For sure future prog types won't have to deal with
such binary decision.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help