Bug 515062

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