/run vs. tmpfiles.d issues

[Paul W. Frields]

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 

-- 
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

[Neal Gompa]

On Mon, Mar 12, 2018 at 9:28 AM, Paul W. Frields <stickster(a)gmail.com&gt; 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:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1553916
>  
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.


-- 
真実はいつも一つ！/ Always, there's only one truth!

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:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1553916 
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(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org

[Paul Frields]

On Mon, Mar 19, 2018 at 8:21 AM,  <cheese(a)nosuchhost.net&gt; 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:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1553916
>
>
>  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.

-- 
Paul