[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQBV1mcFUmXQs1-VKpAVdaAQ3EiGk-G3ybxfcBkoKGwcw@mail.gmail.com>
Date: Tue, 17 Oct 2023 17:20:29 -0400
From: Paul Moore <paul@...l-moore.com>
To: Chris Riches <chris.riches@...anix.com>
Cc: audit@...r.kernel.org, Eric Paris <eparis@...hat.com>,
jonathan.davies@...anix.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] audit: Send netlink ACK before setting connection in auditd_set
On Tue, Oct 17, 2023 at 9:49 AM Chris Riches <chris.riches@...anix.com> wrote:
> On 16/10/2023 21:16, Paul Moore wrote:
> >> While typing it out manually, I noticed that
> >> the condition for sending the ACK isn't correct - if NLM_F_ACK is 0 to
> >> begin with, then ack will be false to begin with, and so no ACK will be
> >> sent even if there is an error.
> >
> > Good point. I'll just casually remind you that I did say "untested" ;)
> >
> > I believe the following should work as intended (untested,
> cut-n-paste, etc.):
> > .....
>
> I think ack must be set to NLM_F_ACK initially - otherwise auditd_set
> will always send the fast-tracked ACK even if the caller did not
> request one.
Another good point. I think I'm working on too many different things
and forgetting the details between our emails :) Sorry about that.
> The following is a concrete version of what I roughly
> suggested in the last email - is there a specific problem you see with
> the (ack || err) condition?
I'm happier with the bool over the integer type for the @ack variable.
I'd suggest updating the patch and posting it again so we can review
it in full, but we weren't very far off last time so I think it should
be close, if not acceptable on the next revision.
> > I'm not sure I can recall everything from when I was thinking about
> > this previously (that was about a week ago), but my quick thoughts
> > right now are that you would need a lot more information and/or
> > handshakes between the kernel and the daemon.
> >
> > Unfortunately, both the current audit design and implementation is
> > seriously flawed in a number of areas. One of these areas is the fact
> > that data and control messages are sent using the same data flow.
>
> Makes sense. The question of why there isn't a separate control socket
> was one of the first we asked while looking into this.
Yeah, there is a lot I would have done differently, but that's the way
it goes sometimes. I have plans to find some of the larger problems,
I just need to find some time to work on it.
--
paul-moore.com
Powered by blists - more mailing lists