John has all the details. I'm just guessing. But having actually looked at the code, commit 2c78ee898d8f1 ie. kernel/bpf/syscall.c: bpf_prog_load() + if (is_net_admin_prog_type(type) && !capable(CAP_NET_ADMIN)) + return -EPERM; looks fishy, since our bpfloader only has CHOWN SYS_ADMIN, and the maps/programs it creates/loads are used by netd which only has NET_ADMIN (but not SYS_ADMIN). Furthermore I don't really want to grant it NET_ADMIN. I think this should again be either NET_ADMIN or SYS_ADMIN. On Thu, Jun 18, 2020 at 12:01 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Wed, Jun 17, 2020 at 11:43 PM Maciej Żenczykowski > <zenczykowski@xxxxxxxxx> wrote: > > > > is > > (SYS_ADMIN || BPF) && NET_ADMIN > > > > should this not be > > SYS_ADMIN || (BPF && NET_ADMIN) > > > > ? > > capable_bpf_net_admin doesn't exist. > > > Won't this cause a just SYS_ADMIN process to fail to load network bpf progs? > > if the process has cap_sys_admin it has all privs. > > > (I haven't debugged this at all, but John is reporting 5.8-rc1 fails > > to load bpf progs from Android's bpfloader with EPERM error) > > > > Or are we okay with this user space visible behavioural change? > > What kind of change? Could you please be more specific?
