On Fri, May 08, 2020 at 03:45:36PM -0700, Casey Schaufler wrote: > On 5/8/2020 2:53 PM, Alexei Starovoitov wrote: > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > 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.
