Re: [PATCH bpf-next 01/10] bpf: move unprivileged checks into map_create() and bpf_prog_load()

[Stanislav Fomichev <sdf@google.com>]

On 05/02, Andrii Nakryiko wrote:
> Make each bpf() syscall command a bit more self-contained, making it
> easier to further enhance it. We move sysctl_unprivileged_bpf_disabled
> handling down to map_create() and bpf_prog_load(), two special commands
> in this regard.
> 
> Also swap the order of checks, calling bpf_capable() only if
> sysctl_unprivileged_bpf_disabled is true, avoiding unnecessary audit
> messages.
> 
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
>  kernel/bpf/syscall.c | 37 ++++++++++++++++++++++---------------
>  1 file changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 14f39c1e573e..d5009fafe0f4 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -1132,6 +1132,17 @@ static int map_create(union bpf_attr *attr)
>  	int f_flags;
>  	int err;

[..]

> +	/* Intent here is for unprivileged_bpf_disabled to block key object
> +	 * creation commands for unprivileged users; other actions depend
> +	 * of fd availability and access to bpffs, so are dependent on
> +	 * object creation success.  Capabilities are later verified for
> +	 * operations such as load and map create, so even with unprivileged
> +	 * BPF disabled, capability checks are still carried out for these
> +	 * and other operations.
> +	 */
> +	if (sysctl_unprivileged_bpf_disabled && !bpf_capable())
> +		return -EPERM;
> +

Does it make sense to have something like unpriv_bpf_capable() to avoid
the copy-paste?