The introduction of non-persistent /run has apparently created an issue where some RPM packages raise verification issues depending on the umask present when a process from that package starts. The issue is further explained in a tracking bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1553916
While arguably not a showstopper for Fedora, it's certainly an annoyance to have RPMs not verify post-installation when a packaged service is started. This situation's also potentially harmful downstream to RHEL. It means that customers who have to go through audit processes for STIG[1] compliance will get dinged (even if explainable) for this packaging issue.
Note that in the tracking bug above, there's a reference to a specific example which was fixed appropriately for resource-agents:
https://bugzilla.redhat.com/show_bug.cgi?id=1462802
Would packaging folks agree that it's worth fixing files not using tmpfiles.d (https://fedoraproject.org/wiki/Packaging:Tmpfiles.d) to do so?
* * * [1] https://iase.disa.mil/stigs/Pages/index.aspx
On Mon, Mar 12, 2018 at 9:28 AM, Paul W. Frields stickster@gmail.com wrote:
The introduction of non-persistent /run has apparently created an issue where some RPM packages raise verification issues depending on the umask present when a process from that package starts. The issue is further explained in a tracking bug here:
Please don't link bugs no one can read.
While arguably not a showstopper for Fedora, it's certainly an annoyance to have RPMs not verify post-installation when a packaged service is started. This situation's also potentially harmful downstream to RHEL. It means that customers who have to go through audit processes for STIG[1] compliance will get dinged (even if explainable) for this packaging issue.
Note that in the tracking bug above, there's a reference to a specific example which was fixed appropriately for resource-agents:
https://bugzilla.redhat.com/show_bug.cgi?id=1462802
Would packaging folks agree that it's worth fixing files not using tmpfiles.d (https://fedoraproject.org/wiki/Packaging:Tmpfiles.d) to do so?
Regardless of the bugs no one can read, I agree moving to tmpfiles.d files makes sense.
On Mon, 12 Mar 2018, Paul W. Frields wrote:
The introduction of non-persistent /run has apparently created an issue where some RPM packages raise verification issues depending on the umask present when a process from that package starts. The issue is further explained in a tracking bug here:
Can not check that bug, as it is an internal one at least i have no permission to read that.
While arguably not a showstopper for Fedora, it's certainly an annoyance to have RPMs not verify post-installation when a packaged service is started. This situation's also potentially harmful downstream to RHEL. It means that customers who have to go through audit processes for STIG[1] compliance will get dinged (even if explainable) for this packaging issue.
Note that in the tracking bug above, there's a reference to a specific example which was fixed appropriately for resource-agents:
https://bugzilla.redhat.com/show_bug.cgi?id=1462802
Would packaging folks agree that it's worth fixing files not using tmpfiles.d (https://fedoraproject.org/wiki/Packaging:Tmpfiles.d) to do so?
+1
[1] https://iase.disa.mil/stigs/Pages/index.aspx
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On Mon, Mar 19, 2018 at 8:21 AM, cheese@nosuchhost.net wrote:
On Mon, 12 Mar 2018, Paul W. Frields wrote:
The introduction of non-persistent /run has apparently created an issue where some RPM packages raise verification issues depending on the umask present when a process from that package starts. The issue is further explained in a tracking bug here:
Can not check that bug, as it is an internal one at least i have no permission to read that.
That's my fault, linked improperly. Ignore it as it's a private bug. It's not useful anyway, the later bug is.
While arguably not a showstopper for Fedora, it's certainly an annoyance to have RPMs not verify post-installation when a packaged service is started. This situation's also potentially harmful downstream to RHEL. It means that customers who have to go through audit processes for STIG[1] compliance will get dinged (even if explainable) for this packaging issue.
Note that in the tracking bug above, there's a reference to a specific example which was fixed appropriately for resource-agents:
https://bugzilla.redhat.com/show_bug.cgi?id=1462802
Would packaging folks agree that it's worth fixing files not using tmpfiles.d (https://fedoraproject.org/wiki/Packaging:Tmpfiles.d) to do so?
+1
Thanks for input here.
packaging@lists.fedoraproject.org
-
cheese＠nosuchhost.net -
Neal Gompa -
Paul Frields -
Paul W. Frields