Bug 1841430

Summary: Don't run wide restorecon in RPM %post* scriptlets
Product: [Fedora] Fedora Reporter: Pavel Raiskup <praiskup>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: dwalsh, grepl.miroslav, lvrabec, mmalik, plautrba, vmojzis, zpytela
Target Milestone: ---   
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: 2020-05-29 07:15:04 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 Pavel Raiskup 2020-05-29 06:47:31 UTC 
This is second time during last 3 months.  It happened to me when I was
running F32 pre-release variant, I sort of accepted it that time because
it was just pre-release distro.

But now when F32 is stable, it doesn't sound acceptable that dnf update
process takes hours because of this.  My update process now hangs on:

...
  Running scriptlet: selinux-policy-targeted-3.14.5-39.fc32.noarch
...

On background:
/sbin/restorecon -e /sys -e /proc -e /dev -e /run -e /mnt -e /var/tmp -e /home -e /tmp -e /dev -i -R -f -

What causes problems is - I suppose - the '/home' directory (several
hundreds of gigabytes, thousands of cloned git repositories with small
files, etc.).

If anything like that is really expected, we should find a way to inform
user that the restorecon needs to be done ... (but automatic start doesn't
sound wise to me, it is really hard to predict how long such update will
take on large and slow disks).
Comment 1 Pavel Raiskup 2020-05-29 06:49:54 UTC 
OK, it wasn't that slow compared to previous F32 pre-release run,
now it was "only" 15 minutes.  But still.
Comment 2 Zdenek Pytela 2020-05-29 07:15:04 UTC 
It is now a known issue, although all the consequences were unexpected till the update to selinux-policy-3.14.5-38.fc32 and did not trigger on testing machines.

The inflicting patch was reverted and the downside was announced on the selinux-policy-3.14.5-39.fc32 update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-886cc9af08

The restorecon run on all filesystems should not appear with skipping the update to selinux-policy-3.14.5-38.fc32.

The length of the restorecon run certainly depends on the number of files on filesystems. We are not aware of any other previous change leading to global restorecon. One of the previous updates removed a module which should take a few dozens of seconds.

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