[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ2a_DdwSZciKNtbbK14sOt5BqbATpmvqMVpR3tJvhMZitHxDw@mail.gmail.com>
Date: Thu, 11 May 2023 18:53:10 +0200
From: Christian Göttsche <cgzones@...glemail.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: selinux@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Alistair Delva <adelva@...gle.com>,
Bart Van Assche <bvanassche@....org>,
Serge Hallyn <serge@...lyn.com>, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v4 4/9] block: use new capable_any functionality
On Thu, 11 May 2023 at 17:35, Christoph Hellwig <hch@...radead.org> wrote:
>
> On Thu, May 11, 2023 at 04:25:27PM +0200, Christian Göttsche wrote:
> > Use the new added capable_any function in appropriate cases, where a
> > task is required to have any of two capabilities.
>
> What is this new function and why should we using it?
Quoting the description from
https://lore.kernel.org/all/20230511142535.732324-10-cgzones@googlemail.com/
:
Add the interfaces `capable_any()` and `ns_capable_any()` as an
alternative to multiple `capable()`/`ns_capable()` calls, like
`capable_any(CAP_SYS_NICE, CAP_SYS_ADMIN)` instead of
`capable(CAP_SYS_NICE) || capable(CAP_SYS_ADMIN)`.
`capable_any()`/`ns_capable_any()` will in particular generate exactly
one audit message, either for the left most capability in effect or, if
the task has none, the first one.
This is especially helpful with regard to SELinux, where each audit
message about a not allowed capability request will create a denial
message. Using this new wrapper with the least invasive capability as
left most argument (e.g. CAP_SYS_NICE before CAP_SYS_ADMIN) enables
policy writers to only grant the least invasive one for the particular
subject instead of both.
> Your also forgot to Cc the block list on the entire series, making this
> page completely unreviewable.
Powered by blists - more mailing lists