Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1671327

Summary: RPM permission validation failed on /var/log/journal using openscap scan
Product: Red Hat Enterprise Linux 7 Reporter: Yogita <ysoni>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Frantisek Sumsal <fsumsal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.6CC: dtardon, jsynacek, kwalker, mhaicman, mmarhefk, openscap-maint, rsahoo, systemd-maint-list, systemd-maint
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-26 12:08:37 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:

Description Yogita 2019-01-31 12:14:30 UTC
Description of problem:

After running a openscap scan the following rule failed :  "xccdf_org.ssgproject.content_rule_rpm_verify_ownership" 

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

How reproducible:

1. Installed a machine with DISA STIG compliant RHEL7.6

2. Created the directory /var/log/journal with root:root and enable persistent logging for systemd journal

3. Verified rpm -Va, looked fine.

4. Rebooted and started systemd-journald.service

And this happened.

[root@localhost ~]# rpm -V systemd
S.5....T.  c /etc/systemd/journald.conf
.M....G..  g /var/log/journal

[root@localhost ~]# ls -ld /var/log/journal
drwxr-sr-x+ 3 root systemd-journal 46 Jan 29 13:18 /var/log/journal

The special permission was added.

So this needs to be checked for systemd why the permission SGID is added for this directory as it's not compliant with DISA STIG.

Comment 2 Jan Synacek 2019-01-31 13:33:18 UTC
(In reply to Yogita from comment #0)
> [root@localhost ~]# rpm -V systemd
> S.5....T.  c /etc/systemd/journald.conf

This makes sense, because you changed the configuration. I'm not sure why these verify bits get shown on a config file that is supposed to be changed.

> .M....G..  g /var/log/journal
> 
> [root@localhost ~]# ls -ld /var/log/journal
> drwxr-sr-x+ 3 root systemd-journal 46 Jan 29 13:18 /var/log/journal

The SGID comes from a tmpfiles.d snippet:

# grep 2755 /usr/lib/tmpfiles.d/systemd.conf
z /run/log/journal 2755 root systemd-journal - -
z /var/log/journal 2755 root systemd-journal - -
z /var/log/journal/%m 2755 root systemd-journal - -

It is set so that everyone in the systemd-journal group gets access to the journal files. Also, systemd-journald itself then doesn't have to care about file permissions and doesn't have to do possible user/group lookups, which in turn (depending on the nsswitch.conf) might cause other services to use the journal, which would result in a deadlock.

Comment 3 Jan Synacek 2019-01-31 13:36:00 UTC
(In reply to Jan Synacek from comment #2)
> (In reply to Yogita from comment #0)
> > [root@localhost ~]# rpm -V systemd
> > S.5....T.  c /etc/systemd/journald.conf
> 
> This makes sense, because you changed the configuration. I'm not sure why
> these verify bits get shown on a config file that is supposed to be changed.

You have to run "rpm -V --noconfig" if you don't want to see that.

Comment 4 David Tardon 2019-01-31 15:35:30 UTC

*** This bug has been marked as a duplicate of bug 1545372 ***

Comment 5 Yogita 2019-03-04 10:12:41 UTC
Hello,

Re-opening this bugzilla case as the duplicate bugzilla case 1545372 is closed as NOTABUG with below explaination -
---------------------------------------------------------------------------------------
The SGID comes from a tmpfiles.d snippet:

# grep 2755 /usr/lib/tmpfiles.d/systemd.conf
z /run/log/journal 2755 root systemd-journal - -
z /var/log/journal 2755 root systemd-journal - -
z /var/log/journal/%m 2755 root systemd-journal - -

It is set so that everyone in the systemd-journal group gets access to the journal files. Also, systemd-journald itself then doesn't have to care about file permissions and doesn't have to do possible user/group lookups, which in turn (depending on the nsswitch.conf) might cause other services to use the journal, which would result in a deadlock.
---------------------------------------------------------------------------------------

Cu for whom this bugzilla case was primarliy opened is having below question -
========================================================================================
I totally agree that the permissions are correct from systemd's perspective but the issue arises when you try to verify the permissions on disk relating to the permissions RPM sets.
Due to the fact that RPM set different permissions then are runtime implemented you will always bump in to this issue. This will, in our case always raise a FAILED status when verifying the system with OpenSCAP (DISA STIG). So to me the problem still exists.
========================================================================================

So here, the prime issue -> After running a openscap scan the following rule failed :  "xccdf_org.ssgproject.content_rule_rpm_verify_ownership" still exists!

Comment 6 RHEL Program Management 2019-03-06 08:13:20 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 8 Kyle Walker 2019-04-26 12:08:37 UTC
Just to make sure that all those cc'd are on the same page. I am moving this bug back to systemd, and closing it in favor of the following:

    1545372 – [SPEC] rpm -V failures
    https://bugzilla.redhat.com/show_bug.cgi?id=1545372

Please follow the resolution process there.

*** This bug has been marked as a duplicate of bug 1545372 ***