Bug 426934 - /dev/null: permission denied
/dev/null: permission denied
Product: Fedora
Classification: Fedora
Component: audit (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Steve Grubb
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-12-28 11:30 EST by sangu
Modified: 2008-01-01 10:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-01 10:40:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description sangu 2007-12-28 11:30:54 EST
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):

How reproducible:

Steps to Reproduce:
1. normal user login
Actual results:

Expected results:

Additional info:
Comment 1 Eric Paris 2007-12-28 18:13:26 EST
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)
Comment 2 Eric Paris 2007-12-28 18:18:37 EST
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....
Comment 3 Eric Paris 2007-12-28 18:27:37 EST
oh yeah, note that the perms are not changed if selinux is enforcing since the
above message is an selinux denial....
Comment 4 Eric Paris 2007-12-28 18:36:05 EST
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
27175 fstat(5, {st_mode=S_IFREG|0640, st_size=638, ...}) = 0

fchmod(0, 0400)  ???????
Comment 5 Eric Paris 2007-12-28 18:53:48 EST
in src/auditd-event.c::open_audit_log()

                        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....
Comment 6 Miloslav Trmač 2007-12-28 19:49:55 EST
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;
Comment 7 Valdis Kletnieks 2007-12-28 22:43:56 EST
Re: comment #3 - the perms certainly *do* get whomped if your SELinux happens to
be in permissive mode at the time....
Comment 8 Steve Grubb 2007-12-29 11:22:25 EST
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.
Comment 9 Eric Paris 2007-12-30 11:21:57 EST
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.
Comment 10 Steve Grubb 2007-12-31 09:31:56 EST
This should be fixed in audit-1.6.4-3. I forgot to change the config parser to
support both 0600 and 0640 perms.
Comment 11 Eric Paris 2007-12-31 11:33:27 EST
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
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....
Comment 12 Steve Grubb 2008-01-01 10:40:50 EST
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.

Note You need to log in before you can comment on or make changes to this bug.