Willy Tarreau <w@xxxxxx> writes:
> On Wed, Oct 28, 2020 at 04:06:02PM -0700, Alexei Starovoitov wrote:
>> On Thu, Oct 29, 2020 at 12:30:49AM +0200, Alon, Liran wrote:
>> > > Guarding /sys/kernel/bpf/vmlinux behind CAP_PERFMON would break a lot
>> > > of users relying on BTF availability to build their BPF applications.
>> > True. If this patch is applied, would need to at least be behind an optin
>> > knob. Similar to dmesg_restrict.
>>
>> It's not going to be applied. If a file shouldn't be read by a user
>> it should have appropriate file permissions instead of 444.
>> Checking capable() in read() is very non-unix way to deal with permissions.
>
> Not only it's a non-unix way, both don't achieve the same goals at all!
>
> One checks for permissions at open() time and may for example allow a
> process to drop its uid after opening, while the other one allows to
> filter who can really read it, particularly in case the FD is inherited
> between processes. With this said, I don't see why there would be a
> special case for this one, it should definitely stick to file permissions
> only.
>From include/linux/bpf.h:
static inline bool bpf_allow_ptr_leaks(void)
{
return perfmon_capable();
}
static inline bool bpf_allow_ptr_to_map_access(void)
{
return perfmon_capable();
}
static inline bool bpf_bypass_spec_v1(void)
{
return perfmon_capable();
}
static inline bool bpf_bypass_spec_v4(void)
{
return perfmon_capable();
}
There's also several cases in bpf_base_func_proto().
So it seems entirely reasonable to suggest that perfmon_capable() is the
right check here.
cheers
