netdev - Re: [PATCH bpf-next] libbpf: Print hint about ulimit when getting permission denied error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Dec 2019 17:08:29 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Alexei Starovoitov <ast@...nel.org>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next] libbpf: Print hint about ulimit when getting permission denied error

Daniel Borkmann <daniel@...earbox.net> writes:

> On Mon, Dec 16, 2019 at 02:52:30PM +0100, Jesper Dangaard Brouer wrote:
>> On Mon, 16 Dec 2019 13:40:31 +0100
>> Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>> 
>> > Probably the single most common error newcomers to XDP are stumped by is
>> > the 'permission denied' error they get when trying to load their program
>> > and 'ulimit -r' is set too low. For examples, see [0], [1].
>> > 
>> > Since the error code is UAPI, we can't change that. Instead, this patch
>> > adds a few heuristics in libbpf and outputs an additional hint if they are
>> > met: If an EPERM is returned on map create or program load, and geteuid()
>> > shows we are root, and the current RLIMIT_MEMLOCK is not infinity, we
>> > output a hint about raising 'ulimit -r' as an additional log line.
>> > 
>> > [0] https://marc.info/?l=xdp-newbies&m=157043612505624&w=2
>> > [1] https://github.com/xdp-project/xdp-tutorial/issues/86
>> > 
>> > Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>> 
>> Acked-by: Jesper Dangaard Brouer <brouer@...hat.com>
>> 
>> This is the top #1 issue users hit again-and-again, too bad we cannot
>> change the return code as it is UAPI now.  Thanks for taking care of
>> this mitigation.
>
> It's an annoying error that comes up very often, agree, and tooling then
> sets it to a high value / inf anyway as next step if it has the rights
> to do so. Probably time to revisit the idea that if the user has the same
> rights as being able to set setrlimit() anyway, we should just not account
> for it ... incomplete hack:

It did always seem a bit odd to me that there was this limit that was
setable by the user it was supposed to limit (for XDP anyway). So I
would totally be in favour of fixing it in the kernel; but probably a
good idea to put the hint into libbpf anyway, for those with older
kernels...

-Toke