The issue is somewhat, though not entirely, related to the following entry in the DISA STIG implementation: CCE-27209-6 Verify and Correct File Permissions with RPM The finding above is related to the mode for files in the RPM database. This essentially boils down to the following command being run on customer systems: # rpm -Va | grep '^.M' For most systems, this isn't a problem. However, it turns out that with the RHEL 7 release, when we backported the Fedora 15 /run non-persistent change [^1], it introduced a subtle packaging issue. With /run and /var/run being ephemeral, our packaging maintainers should have introduced systemd-tmpfiles drop-in configuration files in the event that the specfile includes files in either of these paths. That effort looks to have been very hit-or-miss. An example of this type of specific issue came up back in June and I opened the following with a good outcome: Bug 1462802 – /var/run/resource-agents/ is created with the incorrect mode https://bugzilla.redhat.com/show_bug.cgi?id=1462802 The issue in regards STIG is that you get the following permutations for impacted packages. 1 - Install the RPM - Scan the system - PASS 2 - Restart the system - Service _not_ set to start on boot - Scan the system - PASS 3 - Restart the system - Service _is_ set to start on boot - Scan the system - PASS/FAIL - Depending on the umask present when the process starts vs the mode defined in the RPM spec 3 - Start the application - Scan the sytsem - PASS/FAIL - Depending on the umask present when the process starts vs the mode defined in the RPM spec Fast forward to the end of this year, and we now have a RHEL customer that isn't really concerned with any one particular RPM. They are concerned that any package that isn't currently in compliance could cause a STIG finding to be raised. The ask from them is that we start addressing the issue via individual BZs for any package that has a file in these paths and doesn't include a tmpfiles configuration.
This is set as a tracking bug, but isn't made public. Could we change this to being a public tracker? Or, could we make one which could be public?