Bug 515062 - /var/log/acpid has improper permissions
Summary: /var/log/acpid has improper permissions
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: acpid   
(Show other bugs)
Version: 5.3
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Jiri Skala
QA Contact: BaseOS QE
URL:
Whiteboard:
Keywords:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-07 17:11:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1642 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):

acpid-1.0.4-7.el5_3.1

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:

-r-s-wsr-x
--w---s-wx
-r-------t
-rwS--S-wT

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,
S_IRUSR|S_IWUSR|S_IRGRP);
        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 
#!/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.

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 Product and 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.

http://rhn.redhat.com/errata/RHSA-2009-1642.html


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