diff options
| author | Andrii Nakryiko <[email protected]> | 2024-01-23 18:20:58 -0800 |
|---|---|---|
| committer | Alexei Starovoitov <[email protected]> | 2024-01-24 16:21:00 -0800 |
| commit | ed1ad5a7415de8be121055e7ab1303d2be5407e0 (patch) | |
| tree | b9da489b27e66f93b861aae564e7bb93d70939db /tools/perf/scripts/python | |
| parent | c9f115564561af63db662791e9a35fcf1dfefd2a (diff) | |
bpf: Align CAP_NET_ADMIN checks with bpf_capable() approach
Within BPF syscall handling code CAP_NET_ADMIN checks stand out a bit
compared to CAP_BPF and CAP_PERFMON checks. For the latter, CAP_BPF or
CAP_PERFMON are checked first, but if they are not set, CAP_SYS_ADMIN
takes over and grants whatever part of BPF syscall is required.
Similar kind of checks that involve CAP_NET_ADMIN are not so consistent.
One out of four uses does follow CAP_BPF/CAP_PERFMON model: during
BPF_PROG_LOAD, if the type of BPF program is "network-related" either
CAP_NET_ADMIN or CAP_SYS_ADMIN is required to proceed.
But in three other cases CAP_NET_ADMIN is required even if CAP_SYS_ADMIN
is set:
- when creating DEVMAP/XDKMAP/CPU_MAP maps;
- when attaching CGROUP_SKB programs;
- when handling BPF_PROG_QUERY command.
This patch is changing the latter three cases to follow BPF_PROG_LOAD
model, that is allowing to proceed under either CAP_NET_ADMIN or
CAP_SYS_ADMIN.
This also makes it cleaner in subsequent BPF token patches to switch
wholesomely to a generic bpf_token_capable(int cap) check, that always
falls back to CAP_SYS_ADMIN if requested capability is missing.
Signed-off-by: Andrii Nakryiko <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Acked-by: Yafang Shao <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions