Re: journald vs auditd

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Sa, 24.11.18 14:38, Michał Zegan (webczat_200@xxxxxxxxxxxxxx) wrote:

> Hello,
> 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.

> Because 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.

There's a rhbz bug about this, open since a long long time:

https://bugzilla.redhat.com/show_bug.cgi?id=1160046

It's a pity this work went nowhere...

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel