Re: netlink ACK handling in audit_set_pid()
On 13/11/2023 21:49, Steve Grubb wrote:
The root of the problem is the kernel flooding it's buffers when
the ACK
option is given. It really should reserve space if that socket option is
active. I see Paul merged the patch, so that should work itself out
eventually.
I suppose the same thing can happen when auditd needs signal information. I
think the fix was generic enough to fix this use case also.
Yes, the kernel patch
should help and might be sufficient in most cases,
but it's not perfect.
> I think we should look at improving what we currently have in
the
> meantime - what do you think about the idea of tolerating ENOBUFS?
If we ignore this error, then I think there may be other problems because we
do not really know if the setup is correct. And what if we get ENOBUFS when
sending an audit event to the kernel? We have uncertainty that the event was
sent because under some requirements the application must exit if it can't
record who is doing something. (The code setting the pid and sending events
use the same core functions.)
I agree it's risky to ignore ENOBUFS in general.
But it looks to me like
audit_send() returns -errno, so we could detect and allow it
specifically in audit_set_pid(). I'm not aware of anything that could
cause ENOBUFS at that point in time except the kernel flooding the
socket with messages, which would imply the AUDIT_SET call was
successful (or else we would receive nothing / a single error-ACK).
Tangentially, did you have a chance to look at the wmode=WAIT_YES oddity
I pointed out in my original email?
- Chris
Attachments:
- attachment.html (text/html — 2.2 KB)