audit(1199402245.461:798): avc:  denied  { setattr } for  pid=26857
comm="auditd" name="null" dev=tmpfs ino=1948 scontext=root:system_r:auditd_t:s0
tcontext=system_u:object_r:null_device_t:s0 tclass=chr_file
audit(1199402245.461:798): arch=c000003e syscall=91 success=no exit=-13 a0=0
a1=100 a2=55555576e440 a3=0 items=0 ppid=26856 pid=26857 auid=0 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none), sessionid=5
comm="auditd" exe="/sbin/auditd" subj=root:system_r:auditd_t:s0 key=(null)

that audit message appears in /var/log/messages or dmesg since it appears while
i am running service audit restart and the audit daemon is not actually up at
the moment....

oh yeah, note that the perms are not changed if selinux is enforcing since the
above message is an selinux denial....

27175 open("/var/run/auditd.pid", O_WRONLY|O_CREAT|O_TRUNC|O_NOFOLLOW, 0644) = 5
27175 write(5, "27175\n", 6)            = 6
27175 close(5)                          = 0
27175 open("/var/log/audit/audit.log", O_WRONLY|O_APPEND|O_NOFOLLOW) = 5
27175 fcntl(5, F_SETFD, FD_CLOEXEC)     = 0
27175 fchmod(0, 0400)                   = 0
27175 fchown(5, 0, 0)                   = 0
27175 fcntl(5, F_GETFL)                 = 0x28401 (flags
O_WRONLY|O_APPEND|O_LARGEFILE|O_NOFOLLOW)
27175 fstat(5, {st_mode=S_IFREG|0640, st_size=638, ...}) = 0


fchmod(0, 0400)  ???????

in src/auditd-event.c::open_audit_log()

        fchmod(data->log_fd,
                        data->config->log_group ? S_IRUSR|S_IRGRP : S_IRUSR);
        fchown(lfd, 0, data->config->log_group);

        data->log_fd = lfd;

notice the fchmod is using data->log_fd even though it isn't set until a couple
lines later.  Either the data->og_fd needs to be moved up or the fchmod should
use lfd directly....

As a stopgap, audit-1.6.3-2 removes the fchmod() call.  Merely changing the
fchmod() to use lfd is not enough, because the following code in
log_file_parser() triggers when auditd is started for the second time:
        if ((buf.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)) != 
                          (S_IRUSR|S_IWUSR|S_IRGRP)) {
                audit_msg(LOG_ERR, "%s permissions should be 0640", nv->value);
                return 1;
        }

Re: comment #3 - the perms certainly *do* get whomped if your SELinux happens to
be in permissive mode at the time....

A permanent fix was put in audit-1.6.4-1. This was a case of using the wrong
variable in a fchmod operation. Thanks for reporting the problem. If the 1.6.4
package doesn't work for you, please reopen this bug report.

sgrubb, please reread comment #6

1.6.4-1 is now changing /var/log/audit/audit.log to 600 (which is a large
improvement over /dev/null) but if you then restart auditd it refuses to start
because it is not 640.

This should be fixed in audit-1.6.4-3. I forgot to change the config parser to
support both 0600 and 0640 perms.

The config parser fix in comment #10 fixed the problem from comment #6 but this
go wrong if you already have the file set 440 (no real reason to do this, but
this is slow enough of a path to detect and emit a decent error message)

service auditd stop
chmod 440 /var/log/audit/audit.log
service auditd start   (watch it fail)

audit(1199149402.157:189): avc:  denied  { dac_override } for  pid=12625
comm="auditd" capability=1 scontext=unconfined_u:system_r:auditd_t:s0
tcontext=unconfined_u:system_r:auditd_t:s0 tclass=capability
audit(1199149402.157:189): arch=c000003e syscall=2 success=no exit=-13
a0=2aaaaace5010 a1=20401 a2=0 a3=0 items=0 ppid=12624 pid=12625 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="auditd"
exe="/sbin/auditd" subj=unconfined_u:system_r:auditd_t:s0 key=(null)
audit(1199149402.167:190): audit_pid=0 old=0 by auid=0
subj=unconfined_u:system_r:auditd_t:s0
audit(1199149402.189:191): audit_backlog_limit=320 old=320 by auid=0
subj=unconfined_u:system_r:auditctl_t:s0 res=1
audit(1199149402.189:192): audit_backlog_limit=320 old=320 by auid=0 res=1

auditd needed dac_override to write to the read only file but we don't get to
the chmod fixup before it poops out....

This is fixed in the upstream development code. The original problem this bug
report was opened for seems fixed. If another problem is discovered, please open
a new bug report unless there is a regression on /dev/null. Thanks.