Description of problem: Bad context labels are generated when "yum update" updates selinux-policy together with any other package whose files get labelled differently between the old and new policy. Thus in general selinux-policy must not be updated at the same time as any other package. Currently nothing prevents the bad result of incorrect context labels on files in other packages, if the other package is subject to "yum update" by an invocation which also updates selinux-policy. Version-Release number of selected component (if applicable): selinux-policy-* (ANY version!) How reproducible: every time Steps to Reproduce: 1. Run "yum update" which updates selinux-policy together with any package whose files get different context labels between the old and new policy. 2. 3. Actual results: "error updating chronyd.service: cpio: lsetfilecon" as in Comment #7 in bug #746073 . Expected results: Correct context labels on files in other packages, without any changes to other packages. Therefore, some exclusion mechanism which avoids bad context labels by preventing "yum update" from mixing the update of selinux-policy with an update of any other package during the same invocation. Additional info: Setting High Severity because the standard operating procedure generates labelling errors for files in "random" other packages.
This is really an issue only rpm can solve
Rpm has no clue what a given selinux-policy update might change and what packages it might affect. Also policy updates cannot happen in isolation as the policy packages can (and do) have dependencies of their own, any of which could technically be affected by the policy update as well.
Well if there was a way for a package to tell RPM To reload its SELinux labels, then selinux-policy could tell rpm to do correct labelling from here on in. not sure if there is anyway to communicate with the running rpm from within the postinstall though.
We could probably make rpm detect policy reloads (selinux libs seem to have callbacks for this), but it doesn't help a whole lot if the policy update happens to occur towards the end of the transaction which it very well might: the ordering is calculated from dependencies and since most packages do NOT require selinux-policies then there's nothing to pull it towards the start of the transaction.
Right except the problem that we see is rpm reads in file_context file, runs most of the transaction, SELinux-policy replaces the policy and potentially changes one of the labels that rpm is going to put down in future packages, perhaps invalidating one of the labels. If rpm notices the load_policy through a netlink message, it could reread the file context file and now should be guaranteed the file_context is correct for any other content it lays down. The selinux-policy package is supposed to be fixing any labels that might have changed before the post install ran.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
rpm >= 4.10 automatically reloads the labels if policy changes inside the transaction, so at least we wont be laying down invalid labels and if selinux-policy package fixes the labels before that... I think we can consider this fixed.