Bug 515062 - /var/log/acpid has improper permissions
Summary: /var/log/acpid has improper permissions
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: acpid
Version: 5.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Jiri Skala
QA Contact: BaseOS QE
Depends On:
Blocks: CVE-2009-4033, CVE-2009-4235
TreeView+ depends on / blocked
Reported: 2009-08-01 15:21 UTC by David Tonhofer
Modified: 2018-10-20 03:23 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-12-07 17:11:19 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1642 0 normal SHIPPED_LIVE Important: acpid security update 2009-12-07 17:11:14 UTC

Description David Tonhofer 2009-08-01 15:21:17 UTC
Description of problem:

/var/log/acpid has permissions "---------x", which seems peculiar. 

Version-Release number of selected component (if applicable):


How reproducible:

Seen on fresh install of RHEL 5.3

Comment 1 Jim 2009-08-20 15:58:21 UTC
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:


Comment 2 Jim 2009-08-20 16:32:36 UTC
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

Comment 3 Jim 2009-08-20 17:37:52 UTC
(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,
        if (logfd < 0) {
                fprintf(stderr, "%s: can't open %s: %s\n", progname, 
                        logfile, strerror(errno));

Comment 7 Vincent Danen 2009-11-04 20:57:32 UTC
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 
for in in `seq 1 25`
    rm -f /var/log/acpid >/dev/null 2>&1
    service acpid restart >/dev/null 2>&1
    ls -al /var/log/acpid

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.

Comment 8 Vincent Danen 2009-11-04 22:25:30 UTC
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.

Comment 10 RHEL Program Management 2009-11-06 19:04:10 UTC
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 "?".

Comment 22 errata-xmlrpc 2009-12-07 17:11:19 UTC
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.


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