[PATCH v3 4/5] Audit: multiple subject lsm values for netlabel

[Casey Schaufler]

On 4/30/2025 11:51 AM, Paul Moore wrote:
> On Wed, Apr 30, 2025 at 12:25 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 4/24/2025 3:18 PM, Paul Moore wrote:
>>> On Mar 19, 2025 Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx().
>>>> This is used in netlabel auditing to provide multiple subject security
>>>> contexts as necessary.
>>>>
>>>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
>>>> ---
>>>>  include/linux/audit.h        |  7 +++++++
>>>>  kernel/audit.c               | 28 +++++++++++++++++++++-------
>>>>  net/netlabel/netlabel_user.c |  9 +--------
>>>>  3 files changed, 29 insertions(+), 15 deletions(-)
>>> Other than moving to the subject count supplied by the LSM
>>> initialization patchset previously mentioned, this looks fine to me.
>> I'm perfectly willing to switch once the LSM initialization patch set
>> moves past RFC.
> It's obviously your choice as to if/when you switch, but I'm trying to
> let you know that acceptance into the LSM tree is going to be
> dependent on that switch happening.

Not a problem. Obviously, I'd prefer this patch going in before the
LSM initialization work, but it is your call.

> The initialization patchset is still very much alive, and the next
> revision will not be an RFC.  I'm simply waiting on some additional
> LSM specific reviews before posting the next revision so as to not
> burn out people from looking at multiple iterations.  I've been told
> privately by at least one LSM maintainer that reviewing the changes in
> their code is on their todo list, but they have been slammed with
> other work at their job and haven't had the time to look at that
> patchset yet.  I realize you don't have those issues anymore, but I
> suspect you are still sympathetic to those problems.

Of course. Waiting on reviews can be frustrating.

> If you're really anxious to continue work on this RIGHT NOW, you can
> simply base your patchset on top of the initialization patchset.  Just
> make sure you mention in the cover letter what you are using as a base
> for the patchset.

As I don't anticipate serious changes to your patch set this makes sense.

> If that still doesn't offer any satisfaction, you can always
> incorporate the feedback that I made in v2 that was ignored in your v3
> posting :-P

Yeah, oops on that.