When systemd sends a userspace AVC message (typically because a user tried to start/stop/query a service they didn't have permission for) the message can be longer than 4k. The audit system truncates messages to 4k (fscking dumb, but that's what it does). Systemd should not send messages so long they are likely to hit this. From what I have seen, it is cmdline= which is most likely to have such excessively long input that the useful part of the audit message is lost.
So what should we do? When generating audit messages truncate all strings we include? To which length?
I've decided to reassign to audit userspace. This is not a kernel problem, and not a systemd problem either. The auditd daemon is once again doing something stupid. When we were doing execve audit userspace was stupidly truncating messages to 4096. In the kernel I broke execve arguments into multiple records. Had I been bolder and wiser back in the day I would have refused to make such a change. There is no way to do such a breakup on a user generated audit message. It darn well can be longer than 4k. This is broken in the audit libraries. Please fix the audit libraries.
I don't see any limit that cuts things down to 4K. The buffer is a little bigger than 8K so that it has room for 2 paths at MAX_PATH length + 2 SE Linux contexts + 268 bytes for other information. Its currently 8970 bytes. Can you tell me a little more about how the event was being generated? Specifically, what audit function was being used?
Any info on reproducing this problem?
OK, took a look... in src/core/selinux-access.c, we find this: char buf[LINE_MAX]; vsnprintf(buf, sizeof(buf), fmt, ap); audit_log_user_avc_message(get_audit_fd(), AUDIT_USER_AVC, buf, NULL, NULL, NULL, 0); So, what is LINE_MAX? Its not defined anywhere in systemd's code. So, it must be from /usr/include/bits/posix2_lim.h where its defined as 2K. As stated previously, the audit system allows messages that are a bit over 8K. So, I think you can safely increase the buffer from 2K to 4K or so. Transferring back to systemd since its code is the limiting factor.
I have now changed our code to use a dynamically sized buffer. This way we don't have to make any assumptions about the audit buffer. If libaudit expects people to be able to use statically sized buffers, then it should probably export some suggested size values for that. Until then, doing this dynamically sounds safer for us, so that we don't run in this again.
Libaudit.h defines MAX_AUDIT_MESSAGE_LENGTH. You would want to use a little less than this because that is the maximum including all the things that libaudit adds like terminal, host, exe name, and success/fail. Out of curiosity, do you really feel sure about dynamic allocations in general? You don't worry about heap fragmentation? The audit daemon code uses stack based buffers everywhere possible so that any chance of heap fragmentation is minimized. Thanks for the update...
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Package systemd-201-2.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2 then log in and leave karma (feedback).
Package systemd-201-2.fc18.4: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3 then log in and leave karma (feedback).
Package systemd-201-2.fc18.5: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Package systemd-201-2.fc18.6: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.