Re: multicast listeners and audit events to kmsg

On Do, 23.04.20 09:19, Casey Schaufler (casey(a)schaufler-ca.com) wrote: The audit support in journald is really not about doing "a better job", or being "faster". Totally not. It's about making a common case easy, that's all. There are at least two very different usecases for the audit data: 1. auditing for the purpose of auditing (i.e. government style) 2. people who just want to debug their frickin selinux issues auditd is great for #1. for #2 people don't want to bother, journald is fine, speed or reliability or any such don't matter, the mcast stuff is definitely good enough, and the benefit of collecting the AVCs via audit from earliest boot on is a lot more interesting and important for such uses than to wonder what happens if the queue runs over... I mean, can't you understand that there's a theme here of people wanting to pick up basic audit messages without installing the whole auditd package and running a daemon all the time? CoreOS wants this, and journald implements this for a reason... I am not sure what the big problem would be with just providing us with a control to turn off the kmsg forwarding with a sysctl or netlink command or so, when userspace requests that. if we had that, auditd could do its own thing owning audit, journald could do its own thing with a stream at the side, and we wouldn't step on each others toes. Anyway, I accept this discussion is not leading anywhere, let's end it here. I do sense the condescension, and I don't need more of that. Lennart -- Lennart Poettering, Berlin