linux-kernel - Re: [PATCH v2 1/4] perf trace: substitute CAP_SYS_ADMIN with CAP

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]

Message-ID: <a775fef2-6d86-d43a-3a46-5b2d129c77dc@linux.intel.com>
Date:   Thu, 23 Apr 2020 17:49:32 +0300
From:   Alexey Budankov <alexey.budankov@...ux.intel.com>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:     Jiri Olsa <jolsa@...hat.com>, Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "selinux@...r.kernel.org" <selinux@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] perf trace: substitute CAP_SYS_ADMIN with
 CAP_PERFMON in error message


On 23.04.2020 16:20, Arnaldo Carvalho de Melo wrote:
> Em Wed, Apr 22, 2020 at 05:44:02PM +0300, Alexey Budankov escreveu:
>>
>> Update error message to mention CAP_PERFMON only. CAP_SYS_ADMIN still
>> works in keeping with user space backward compatibility approach.
> 
> This will confuse users that build the latest perf to use in older
> systems where CAP_PERFMON isn't available, probably we need to, in these
> cases, check for the existence of CAP_PERFMON to provide a better
> warning message, something like:
> 
>   You need CAP_ADMIN or update your kernel and libcap to one that supports
>   CAP_PERFMON.
> 
> For systems without CAP_PERFMON, while mentioning only CAP_PERFMON for
> systems where it is present, right?

Right, but this ideal implementation requires more effort, so staying with
two caps in the message and letting users decide which one to use looks like
a good balance already. 

Thanks,
Alexey