[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1792748b-9204-c96e-b9c6-367eb19928cb@6wind.com>
Date: Wed, 13 Oct 2021 14:29:17 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Lorenz Bauer <lmb@...udflare.com>
Cc: Luke Nelson <luke.r.nels@...il.com>,
Jonathan Corbet <corbet@....net>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
kernel-team <kernel-team@...udflare.com>,
linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH v2 4/4] bpf: export bpf_jit_current
Le 13/10/2021 à 10:35, Lorenz Bauer a écrit :
> On Tue, 12 Oct 2021 at 17:29, Nicolas Dichtel <nicolas.dichtel@...nd.com> wrote:
>>
>> Le 12/10/2021 à 15:59, Lorenz Bauer a écrit :
>>> Expose bpf_jit_current as a read only value via sysctl.
>>>
>>> Signed-off-by: Lorenz Bauer <lmb@...udflare.com>
>>> ---
>>
>> [snip]
>>
>>> + {
>>> + .procname = "bpf_jit_current",
>>> + .data = &bpf_jit_current,
>>> + .maxlen = sizeof(long),
>>> + .mode = 0400,
>> Why not 0444 ?
>
> This mirrors what the other BPF related sysctls do, which only allow
> access from root with CAP_SYS_ADMIN. I'd prefer 0444 as well, but
> Daniel explicitly locked down these sysctls in
> 2e4a30983b0f9b19b59e38bbf7427d7fdd480d98.
Even after this patch, bpf_jit_enable is 0644.
In fact, if you have CAP_BPF or CAP_SYS_ADMIN, this value has no impact for your
programs. But I you don't have one of these capabilities, it may be rejected,
but you cannot read these values, which help to understand why.
Regards,
Nicolas
Powered by blists - more mailing lists