Fact checking

Posted May 30, 2014 17:16 UTC (Fri) by luto (guest, #39314)
In reply to: Fact checking by bnorris
Parent article: Who audits the audit code?

Try running your favorite syscall-heavy workload and seeing if __audit_syscall_xyz shows up.

To be clear: I don't really object to CONFIG_AUDIT -- it's just CONFIG_AUDITSYSCALL. Once audit has been enabled, you're stuck with syscall auditing overhead until the next reboot. There's a workaround:

# auditctl -a task,never

I'm currently lobbying for Fedora to turn off syscall auditing in their default configuration:

https://fedorahosted.org/fesco/ticket/1311

Fact checking

Posted Jun 1, 2014 5:13 UTC (Sun) by dirtyepic (guest, #30178) [Link] (6 responses)

Isn't AUDITSYSCALL required for consolekit to work properly?

Fact checking

Posted Jun 1, 2014 5:21 UTC (Sun) by luto (guest, #39314) [Link]

Wow. That's hideous.

I have no clue what loginuid and sessionid (which appears to be completely unrelated to the POSIX session id) have to do with syscall auditing. It would be easy to split that out from CONFIG_AUDITSYSCALL, since it seems to be almost completely unrelated to syscall auditing, other than the fact that syscall auditing logs the loginuid and sessionid.

Fact checking

Posted Jun 3, 2014 19:48 UTC (Tue) by zdzichu (guest, #17118) [Link] (4 responses)

ConsoleKit is so dead and so irrelevant today, it's not worth a dime.

Fact checking

Posted Jun 4, 2014 4:24 UTC (Wed) by dirtyepic (guest, #30178) [Link] (3 responses)

I can't argue that, but it's disappointing. Systemd isn't really an option here (in fact it's proven impossible for us to make any kind of big change - we're still on cvs FFS).

Fact checking

Posted Jun 14, 2014 9:19 UTC (Sat) by Duncan (guest, #6647) [Link] (2 responses)

Systemd requires it too (or at least gentoo's systemd ebuild checks for it and warns if the thing isn't enabled), probably for exactly the same thing consolekit uses it for, if not more.

But no sign of kauditd. I might just try disabling CONFIG_AUDIT or at least CONFIG_AUDITSYSCALL next time I do a kernel build and see if systemd can run properly with it disabled. I've wondered why I actually needed it ever since I first enabled it. At least that way if I have to actually reenable it, I'll know exactly what I was unbreaking by doing so.

Fact checking

Posted Jun 14, 2014 13:56 UTC (Sat) by Duncan (guest, #6647) [Link] (1 responses)

Well, whatever systemd "requires" CONFIG_AUDIT for, doesn't seem to affect me turning it off. I rebuild without it, rebooted, logged in, started X... launched a terminal window and zgrepped /proc/config.gz for CONFIG_AUDIT to verify I hadn't somehow booted the old kernel... Loaded up firefox and LWN again to write this update...

Still don't know what systemd "requires" it for, but it's off now and doesn't seem to hurt me, so... I'm leaving it off.

Fact checking

Posted Jun 16, 2014 11:13 UTC (Mon) by cortana (subscriber, #24596) [Link]

It's funny because systemd's README explicitly instructs users who want to run systemd inside a container to disable the audit subsystem.