Description of problem: /var/log/acpid has permissions "---------x", which seems peculiar. Version-Release number of selected component (if applicable): acpid-1.0.4-7.el5_3.1 How reproducible: Seen on fresh install of RHEL 5.3
This also effects installations upgraded from earlier releases when the acpid service recreates the log file. If you remove /var/log/acpid, and restart the daemon, you get seemingly random modes. I got the following in 4 tests: -r-s-wsr-x --w---s-wx -r-------t -rwS--S-wT
On a new system (32bit), a trace of acpid shows that the log file is created withe the system call: open("/var/log/acpid", O_WRONLY|O_CREAT|O_APPEND, 01) which creates the '"---------x" mode seen by the OP. On my existing 64bit system, the system call looks like the following from 4 consecutive tests: open("/var/log/acpid", O_WRONLY|O_CREAT|O_APPEND, 0152316360077060374) open("/var/log/acpid", O_WRONLY|O_CREAT|O_APPEND, 0152320420362545134) open("/var/log/acpid", O_WRONLY|O_CREAT|O_APPEND, 0152321314513500615) open("/var/log/acpid", O_WRONLY|O_CREAT|O_APPEND, 0152325150212171456) The open() call in acpid.c looks normal though line 445: logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND); not sure what's going on here
(In reply to comment #2) > The open() call in acpid.c looks normal though > line 445: > logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND); > > not sure what's going on here Oh, that's the answer right there. File mode *must* be specified when the O_CREATE flag is used. test patch: diff --git a/acpid.c b/acpid.c index c16cf0d..e35ce43 100644 --- a/acpid.c +++ b/acpid.c @@ -432,7 +432,7 @@ open_logs(void) "/dev/null", strerror(errno)); return -1; } - logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND); + logfd = open(logfile, O_WRONLY|O_CREAT|O_APPEND, S_IRUSR|S_IWUSR|S_IRGRP); if (logfd < 0) { fprintf(stderr, "%s: can't open %s: %s\n", progname, logfile, strerror(errno));
This looks like it might be specific to Red Hat Enterprise Linux 5. On 3/x86_64 (exclusivearch excludes x86), I get 0640 permissions each time on 25 iterations of a test, and likewise with 4 (both 32bit and 64bit). On Red Hat Enterprise Linux 5 32bit, on 25 iterations, permissions were always 0001, whereas on 64bit they were all over the place as noted in #c1. Used the following to test: % cat acpid-test.sh #!/bin/sh for in in `seq 1 25` do rm -f /var/log/acpid >/dev/null 2>&1 service acpid restart >/dev/null 2>&1 ls -al /var/log/acpid done Looking at the code, however, shows the same open() call, so it's nothing in the code that is making this difference. Could there be a difference in the way open() is implemented between EL5 and EL4? Perhaps some change to glibc? At any rate, this does not seem to affect Red Hat Enterprise Linux 3 or 4, just 5.
The issue is also in the daemonize() function. It calls umask(0) when there really is no need for it. Removing umask(0) in addition to the permission changes noted in the patch in #c3 corrects the issue.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
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/RHSA-2009-1642.html