Well, actually I would like a feature to filter out audit data when
looking at logs. I often do things like journalctl -o cat -f or
unit or whatever, and in some cases I see a ton of those. I believe
Post by Michał ZeganHello,
Does journald intent to replace auditd?
Well, no.
I mean, there's some useful log data generated through the audit
framework that is not available elsewhere, and I think it's useful do
have this among the rest of the log data, hence we added support for
collecting that data. However, journald cannot replace auditd in most
ways, it will only register itself as an additional listener to audit
messages but not as the userspace consumer of it, like auditd
does. And that's on purpose: if you want the full auditd subsystem use
auditd really. journald is just an additional consumer of the data,
that is all, and it doesn't want to take full possession of the audit
stream like auditd does.
Post by Michał ZeganBecause it has ability to get audit messages and uses it by default,
also turning on audit. On the other hand, it does not silence dmesg
audit messages like auditd seems to do, why?
So, yeah, this sucks a bit. This is a kernel limitation. There has
been some work on fixing this in the kernel, but it never was
finished. Right now the implemented logic in the kernel is that only
if a userspace consumer of audit is running then the forward-to-kmsg
logic in the kernel is turned off and additional listeners (such as
journald) do not effect that logic. The idea of the unfinished work
was that the kernel would be changed to turn off the forward-to-kmsg
as soon as either a consumer is active or when at least one additional
listener is active.
https://bugzilla.redhat.com/show_bug.cgi?id=1160046
It's a pity this work went nowhere...
Lennart