Bug 1182317

Summary: Wrong permission of /var/account/pacct in psacct package
Product: Red Hat Enterprise Linux 6 Reporter: Paulo Andrade <pandrade>
Component: psacctAssignee: Jan Rybar <jrybar>
Status: CLOSED ERRATA QA Contact: Branislav Náter <bnater>
Severity: medium Docs Contact: Lenka Kimlickova <lkimlick>
Priority: medium    
Version: 6.6CC: bnater, fkrska, igreen, pandrade, tlavigne
Target Milestone: rcKeywords: EasyFix, FastFix, Patch, Reproducer
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: psacct-6.3.2-67.el6 Doc Type: Bug Fix
Doc Text:
RPM verification no longer reports failures in the `/var/account/pacct` file Previously, the RPM verification and compliance check reported failures, because the mode of the `/var/account/pacct` file was not set after installation. To fix this bug, the mode of `/var/account/pacct` is changed immediately after installation to 0600. As a result, the RPM verification check no longer reports failures in the `/var/account/pacct`, and the file is now accessible only by root.
Story Points: ---
Clone Of:
: 1249665 (view as bug list) Environment:
Last Closed: 2017-03-21 11:40:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1002711, 1182318, 1182319, 1249665, 1269194, 1356056, 1359260    

Description Paulo Andrade 2015-01-14 20:31:33 UTC
RPM psacct specifies the file /var/account/pacct as a ghost file with permissions 640, but after installation the file has permission 644, causing rpm verficiation and subsequent compliance check failures.

A simple psacct.spec pseudo patch would be:

-%attr(0600,root,root)   %ghost %config %{accounting_logdir}/pacct
+%attr(0644,root,root)   %ghost %config %{accounting_logdir}/pacct

Comment 2 Jaromír Cápík 2015-01-29 18:58:52 UTC
Hello Paulo.

I just tested that on RHEL5 and RHEL6 and the file permissions are 0600 in both cases (and that's correct). I probably don't understand what you're trying to say/achieve. Could you please be more verbose?

Thanks,
Jaromir.

Comment 3 Jaromír Cápík 2015-01-29 19:03:38 UTC
Well ... few days ago I had a report about 'atop' conflicting with psacct/logrotate. Could you please check, whether you have 'atop' installed.

Comment 4 Paulo Andrade 2015-01-29 19:52:22 UTC
Hi Jaromír,

This bug report is a kind of a sibling of
https://bugzilla.redhat.com/show_bug.cgi?id=1182304

I personally do not have an "atop" package, but I see,
on rhel-7:

$ LC_ALL=C ls /var/account/pacct -la
-rw-r--r--. 1 root root 0 Dec  9 10:37 /var/account/pacct

Comment 5 Jaromír Cápík 2015-08-03 13:13:21 UTC
Hi Paulo.

Does it mean the bug was reported against wrong RHEL version?

Thx, J.

Comment 6 Jaromír Cápík 2015-08-03 13:17:26 UTC
I just checked RHEL7 and the permissions are 0600 there too. Could you please attach your /etc/logrotate.d/psacct file?

Comment 7 Jaromír Cápík 2015-08-03 13:19:04 UTC
The thing is, that the logrotate file is marked as %config(noreplace) and for some reason you might have an old/wrong version of that file and it doesn't get replaced with the latest one.

Comment 8 Jaromír Cápík 2015-08-03 14:10:38 UTC
Summary
========
The file permissions in the CPIO archive are really 644 since the ghost entries do not fix file permissions. Therefore the following spec lines need to be equipped with a permission modification:

  mkdir -p %{buildroot}/var/account
  touch %{buildroot}/var/account/pacct

Comment 9 Jaromír Cápík 2015-08-03 14:13:47 UTC
diff --git a/psacct.spec b/psacct.spec
index 49fef5c..2543d0d 100644
--- a/psacct.spec
+++ b/psacct.spec
@@ -85,7 +85,7 @@ cp dump-acct.8 %{buildroot}%{_mandir}/man8/
 rm -f %{buildroot}%{_infodir}/dir
 
 mkdir -p %{buildroot}/var/account
-touch %{buildroot}/var/account/pacct
+touch %{buildroot}/var/account/pacct && chmod 0600 %{buildroot}/var/account/pacct
 
 # create logrotate config file
 mkdir -p %{buildroot}/etc/logrotate.d

Comment 21 errata-xmlrpc 2017-03-21 11:40:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0770.html