SEL: double restorecon on systemupgrade F31->F32

[Marius Schwarz]

Hi,

while upgrading from F31 to F32, the selpolicy script has executed a
full restorecon on any main path (/*):

once after installing the package and once on removing the old package (
aka house keeping the old package ).

As it's not directly a bug, more an intense waste of time and IO, i did
not open a br for it. Every restorecon took about 50s to 1 minute on a
12Gb/s ssd raid. If it could be combined to only one run at the end, it
would be ok. The system in question was freshly installed with F31 and
updated before upgrading to F32.

The next question would be, if there is better way to set se contexts on
the entire filesystem, but thats a whole different story.

best regards,
Marius

[Chris Murphy]

On Mon, May 11, 2020 at 12:55 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote:
>  Hi,
>
>  while upgrading from F31 to F32, the selpolicy script has executed a
>  full restorecon on any main path (/*):
>
>  once after installing the package and once on removing the old package (
>  aka house keeping the old package ).
>
>  As it's not directly a bug, more an intense waste of time and IO, i did
>  not open a br for it. Every restorecon took about 50s to 1 minute on a
>  12Gb/s ssd raid. If it could be combined to only one run at the end, it
>  would be ok. The system in question was freshly installed with F31 and
>  updated before upgrading to F32. 
Should (or are) systemd upgrades done in permissive mode to make
certain they can't fail? In which case a pre-relable isn't needed
(probably, I guess there are some exceptions that can result in denial
even in permissive mode?), just the post-upgrade relabel. And maybe it
should be specific to /usr /var /etc/ /boot? I don't think everything
in fstab is assembled in this minimal environment anyway, but I'm not
certain about stomping on everything without being deliberate about
it, in particular /home /opt and /srv.


-- 
Chris Murphy

[Petr Lautrbach]

It's already reported - https://bugzilla.redhat.com/show_bug.cgi?id=1832327

It's `fixfiles` issue related to the following file context change:

    + /s?bin/arping  --      system_u:object_r:netutils_exec_t:s0
    - /sbin/arping   --      system_u:object_r:netutils_exec_t:s0

`fixfiles` script tries to detect all changes in file contexts and runs `restorecon` only
on files with changed context. Unfortunately the logic in `fixfiles` interprets
'/s?bin/arping' as '/*' and runs `restorecon` on '/*'