Hide Forgot
Description of problem: Logging does not resume to audit.log after resume from SYSLOG on full disk action and user type messages continue to go to /var/log/messages. It should be noted that a record about successfull resume goes to audit.log eventually: type=DAEMON_RESUME msg=audit(1300385209.456:8846): auditd resuming logging, sending auid=? pid=? subj=? res=success Version-Release number of selected component (if applicable): audit-2.0.6-1.el6.x86_64 How reproducible: always Steps to Reproduce: 1. Update a default /etc/aduitd/auditd.conf to use SYSLOG actions -admin_space_left_action = SUSPEND -disk_full_action = SUSPEND -disk_error_action = SUSPEND +admin_space_left_action = syslog +disk_full_action = syslog +disk_error_action = syslog 2. Simulate a full disk where audit.log is located (more details later), and wait for a message in /var/log/messages: <snip> ar 17 13:06:25 dhcp-24-228 auditd[5523]: Audit daemon has no space left on logging partition Mar 17 13:06:25 dhcp-24-228 auditd[5523]: Audit daemon has no space left on logging partition Mar 17 13:06:25 dhcp-24-228 auditd[5523]: Record was not written to disk (No space left on device) Mar 17 13:06:25 dhcp-24-228 auditd[5523]: write: Audit daemon detected an error writing an event to disk (No space left on device) Mar 17 13:06:25 dhcp-24-228 auditd[5562]: Audit daemon failed to exec (null) Mar 17 13:06:25 dhcp-24-228 auditd[5562]: The audit daemon is exiting. Mar 17 13:06:25 dhcp-24-228 kernel: type=1305 audit(1300385185.779:403): audit_pid=0 old=5523 auid=501 ses=4 subj=unconfined_u:system_r:auditd_t:s0 res=1 Mar 17 13:06:25 dhcp-24-228 auditd[5523]: Record was not written to disk (No space left on device) Mar 17 13:06:25 dhcp-24-228 auditd[5523]: write: Audit daemon detected an error writing an event to disk (No space left on device) Mar 17 13:06:25 dhcp-24-228 auditd[5563]: Audit daemon failed to exec (null) Mar 17 13:06:25 dhcp-24-228 auditd[5563]: The audit daemon is exiting. Mar 17 13:06:25 dhcp-24-228 kernel: type=1305 audit(1300385185.846:404): audit_pid=0 old=0 auid=501 ses=4 subj=unconfined_u:system_r:auditd_t:s0 res=1 </snip> User messages (e.g. send by auditctl -m hello) now go to /v/l/messages 3. Make again some space on the logging disk (e.g. by removing the trash you've put the in prvious step), and trigger to resume the logging: # service auditd resume 4. Send an user space message with # auditcl -m hello_world Actual results: Messages continue to end in /v/l/messages instead of audit.log after the resume. Mar 17 13:07:02 dhcp-24-228 kernel: type=1005 audit(1300385222.277:411): user pid=5597 uid=0 auid=501 ses=4 subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 msg='hello_world exe="/sbin/auditctl" hostname=? addr=? terminal=pts/0 res=success' Expected results: Messages end in audit.log after the resume. type=USER msg=audit(1300385164.838:392): user pid=5533 uid=0 auid=501 ses=4 subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 msg='hello_world : exe="/sbin/auditctl" hostname=? addr=? terminal=pts/0 res=success' Additional info: This seems to happen only with SYSLOG action. Action SUSPEND works as expected and the logging is resumted to audit.log correctly.
Client side message in /var/log/messages for syslog action when server signalling low disk space could be improved. Currently it logs something like this: <snip> Mar 17 09:06:47 x86-64-v07 audisp-remote: remote disk low, </snip>
After reviewing the code, I have a couple things to report. The syslog option does not suspend logging. Choosing it means that you get a syslog message each failure. That said, the above log shows a real bug. It says that it cannot exec (null). That means that it was calling the safe_exec function which forks and tries to execute a child process and fails because the program is NULL. This seems to be what is messing things up.
(In reply to comment #2) > After reviewing the code, I have a couple things to report. The syslog option > does not suspend logging. Choosing it means that you get a syslog message each > failure. Yes, I should have used word "return" instead of resume in the bug report. Though there might be a possible issue with action SUSPEND in audisp-remote plugin is that it does not resume on SIGUSR2 e.g "service auditd resume", unless there is a different procedure for resuming the plugin. Could you please have a look into that? (I haven't tried to send it directly to the plugin yet, e.g kill -S usr2 audisp-remote). > That said, the above log shows a real bug. It says that it cannot exec > (null). That means that it was calling the safe_exec function which forks and > tries to execute a child process and fails because the program is NULL. This > seems to be what is messing things up.
audit-2.1-1.el6 was build to resolve this problem.
(In reply to comment #3) > (In reply to comment #2) > > After reviewing the code, I have a couple things to report. The syslog option > > does not suspend logging. Choosing it means that you get a syslog message each > > failure. > > Yes, I should have used word "return" instead of resume in the bug report. > > Though there might be a possible issue with action SUSPEND in audisp-remote > plugin is that it does not resume on SIGUSR2 e.g "service auditd resume", > unless there is a different procedure for resuming the plugin. Could you please > have a look into that? (I haven't tried to send it directly to the plugin yet, > e.g kill -S usr2 audisp-remote). The audisp-remote plugin process will resume logging when it received a SIGUSR2 signal directly. The auditd/audispd does not send SIGUSR2 signals to running registered plugins.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0653.html