Description of problem: normal user login -bash: /dev/null: permission denied -bash: /dev/null: permission denied -bash: /dev/null: permission denied ... Version-Release number of selected component (if applicable): 1.6.3-1.fc9 How reproducible: always Steps to Reproduce: 1. normal user login 2. 3. Actual results: Expected results: Additional info:
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.