On Monday, November 13, 2023 9:43:07 AM EST Chris Riches wrote: > On Thursday, November 9, 2023 12:09:15 PM EST Steve Grubb wrote: > >> I was hoping some other people working on audit would step up. > >> > >> One idea I have not tested is to make a "command and control" fd that > >> would be used for enabling the audit system and setting the pid. This > >> would be separate from the data fd which processes events. > > > > Looks like we lost that ability a couple years ago when missing auditd > > detection was added. The fd that sets the pid is the one that gets all > > the events even if there is another fd available that belongs to the same > > pid. > > Yes, I agree that a separate socket for control vs. messages would be > the best solution, and I briefly discussed this with the kernel > maintainer too. However, as you point out this is not possible today.
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. > 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.) -Steve _______________________________________________ Linux-audit mailing list -- linux-audit@lists.linux-audit.osci.io To unsubscribe send an email to linux-audit-le...@lists.linux-audit.osci.io
