On Di, 10.04.18 12:02, Mikhail Morfikov (mmorfi...@gmail.com) wrote: > I'm using AppArmor and it sometimes returns many audit logs. By default there > was something like this in the journal: > > ... audit[1397]: AVC apparmor= ... > ... kernel: audit: type=1400 audit(1523275695.613:76): apparmor= ... > > So there are two entries and they carry the same message. So the message is > doubled. The first message disappears when systemd-journald-audit.socket is > masked, but what about the second message? > > Basically I want to remove the AppArmor logs only from the journal and not > from > the whole system. They could be logged by rsyslog and placed in some file/FIFO > device. > > Is there a way to get rid of the second message from the journal only somehow?
The kernel has three ways to pass audit messages to userspace: 1. with an audit daemon. This is what auditd implements. It's an exclusive interface: there can only be one userspace service be listening to this, and there is one, nobody else can use the same interface. 2. If there's no userspace process implementing the above, then the messages are instead written directly to kmsg. 3. There can be any number of additional "multicast" audit clients. The journal is one of them, and this is what you can turn off by masking the socket unit you found. Note that this interface is fully orthogonal to #1 and #2. The duplicate messages are you seeing come from #2 and #3 most likely. You were able to disable #3, which leaves you with #2. From the journal's perspective these messages are superficially undistinguishable from other kernel log messages, which means you can turn this off by turnining off all kernel log messages (ReadKmsg= in journald.conf), but of course, in that case you actually turn them *all* off, which is unlikely what you want... A dirty way out is to make sure #1 exists, i.e. by installing auditd. If you do, then #2 won't be in effect anymore, but of course, that has other issues again... There were plans to change the kernel internal logic to only do #2 if there are zero #1 and zero #3 clients around. (Right now #2 is done whenever there are zero #1 clients, and #3 clients don't matter.) That work appears to have stalled though... If you don't care at all about audit messages, consider passing audit=0 on the kernel cmdline, that makes them go away altogether. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
