From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD2E6C4CECD for ; Mon, 16 Sep 2019 22:20:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B16EF21670 for ; Mon, 16 Sep 2019 22:20:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FvbOBGj3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733133AbfIPWT7 (ORCPT ); Mon, 16 Sep 2019 18:19:59 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:46539 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728917AbfIPWT7 (ORCPT ); Mon, 16 Sep 2019 18:19:59 -0400 Received: by mail-pg1-f194.google.com with SMTP id a3so755292pgm.13; Mon, 16 Sep 2019 15:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8UPkN0k3OkeEe5RVBJgSIzoiC+//Dzbo9hfdnEI4PA0=; b=FvbOBGj3R8DqdGK0/5UefMBFXEROkPq4DDIShm+vvlHDppN8KYeHgTr5Mh4BWkTg3r ksKvj/3uVJnehLyFgDW1b19qjH5QmjmbMcf6Z4ZiuDv0hpUPRMdTHTsFHKM89DY8JSKr WX9KFakk3hgiKp9xiD/s8JUZBhFec6ZCpkJuE8v2+hmDwqHGJe1nK60LzpkxcCqwbCXT VlZpM2j88CLoZs267gbP3CywSj4cf1eWvZ7RPdNHC1RFBJYfWEUQyQH6EkhL1YIZj8PI W2cxBKuVSFFkTx0iQYVRmUwlz2yyWPPDoRkYOQoboFipZBqMwz5dR6glyUVJsIH2W5N5 VbmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8UPkN0k3OkeEe5RVBJgSIzoiC+//Dzbo9hfdnEI4PA0=; b=i5MXDQxIaeXJbeqs3o/T+PeSff+SRqqnQvd7qQE4BdfO3CCpIlA88GcOD+OL94pLeq MEChNeCduXz2WjzLUekgc0XR84psrQvSqBmMfcrALRIOz/wU++316cmf0nJvBMnpJm8K K1AZo6z75rl9BnGSVr5spKjJJSI+gILOR1FCOS+WyVWcPz9XK+7XHnuJDj0vv1NVjk4Q 6QOENtuE8g4w36QaaBzKlTzuVEtKORMDwHZmdpCXRlmTbRGUUSeqwpyw0k1EpZnD1Xdq RHLS09g8vDHsqXo4OwQwRCULmqdWI+6BIli7KT3vnBM+0UqSv0aiAwS58qlA2bCPza6L DCqg== X-Gm-Message-State: APjAAAV1hs3uxe026nYcNkvM/U/a9AfWh8JHqLsIpIC8pwgqMdTS1oQY bt9TUUxXm+lLU0qpwaA3V2w= X-Google-Smtp-Source: APXvYqzEtcFgFdGhZnGrAsLh5bwceSi2fn9huT0JXWl0jMtxI+QnVBcxv/GJK0eLMjVdIXZHff/H7g== X-Received: by 2002:a62:5ac1:: with SMTP id o184mr672863pfb.67.1568672398573; Mon, 16 Sep 2019 15:19:58 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:200::2:9e66]) by smtp.gmail.com with ESMTPSA id f20sm82638pgg.56.2019.09.16.15.19.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 15:19:57 -0700 (PDT) Date: Mon, 16 Sep 2019 15:19:56 -0700 From: Alexei Starovoitov To: Christian Barcenas Cc: Daniel Borkmann , Alexei Starovoitov , netdev@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , bpf@vger.kernel.org Subject: Re: [PATCH bpf] bpf: respect CAP_IPC_LOCK in RLIMIT_MEMLOCK check Message-ID: <20190916221954.evj7er2xk22geyst@ast-mbp> References: <20190911181816.89874-1-christian@cbarcenas.com> <678ba696-4b20-5f06-7c4f-ec68a9229620@iogearbox.net> <4f8b455e-aa11-1552-c7f1-06ff63d86542@cbarcenas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4f8b455e-aa11-1552-c7f1-06ff63d86542@cbarcenas.com> User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Sep 16, 2019 at 07:09:06AM -0700, Christian Barcenas wrote: > > bpf() is currently the only exception to the above, ie. as far as I can tell > it is the only code that enforces RLIMIT_MEMLOCK but does not honor > CAP_IPC_LOCK. Yes. bpf is not honoring CAP_IPC_LOCK comparing to other places in the kernel, but we cannot change this anymore. User space already using rlimit as an enforcement. bpf_rlimit.h hack we use in selftests is not a universal way of loading bpf progs. If we make such change root user will become unlimited and rlimit enforcement will break.