Hide Forgot
My upgrade from RHEL 6.1 to 6.2 didn't work as expected. The upgrade updated sssd from version 1.5.1-34.el6_1.3.i686 to 1.5.1-66.el6.i686 In the same yum transaction selinux policy was upgraded from version 3.7.19-93.el6_1.7.noarch to 3.7.19-126.el6_2.3.noarch Unfortunately within the transaction apparently sssd was upgraded and restarted before the selinux policy. This left the sssd monitor process unable to properly start the data providers and the nss and pam backends. After a few tries the monitor gave up and was left idle unable to serve any requests. After logging to a console as root the audit.log showed denials. Simply restarting sssd through the init scripts resolved the issue, so it seem a clear indication that the sssd was restarted before the selinux policy it depdned on was in place. This left the machine in an unusable state for sssd-bound users until root intervention.
Some additional information about the problem: sssd-1.5.1-66.el6 made some changes that required new SELinux policy (if SELinux is installed). Because it is possible to install SSSD on a system without the selinux-policy package installed, we were instructed to use: Conflicts: selinux-policy < 3.7.19-118 This should ensure that the policy version must be 3.7.19-118 or later in order to install this version of SSSD. Unlike using Requires:, this will not forcibly install selinux-policy if it's not currently on the system. The problem is that the yum depsolver does not treat optional-requires of this construction the same way that it treats Requires: There is no guarantee by the depsolver that the policy will be updated before SSSD is. As a result, while the final state of the yum transaction included the correct versions of both of these packages, because the updated selinux-policy was not installed before SSSD, it fails to successfully restart SSSD on upgrade.
Yup, conflicts aren't considered on ordering. This case does suggest they should be, but I'll need to mull over it a bit to consider whether doing so would have any negative side-effects.
> The problem is that the yum depsolver does not treat optional-requires of this > construction the same way that it treats Requires: > > There is no guarantee by the depsolver that the policy will be updated before > SSSD is. As a result, while the final state of the yum transaction included the > correct versions of both of these packages, because the updated selinux-policy > was not installed before SSSD, it fails to successfully restart SSSD on > upgrade. With the rawhide rpm you can enforce installing the new selinux-policy before the new sssd with OrderWithRequires: selinux-policy This won't create a requirement on selinux-policy yet will ensure selinux-policy is installed before sssd if whenever they are in the same transaction.
What kind of selinux policy change are we talking about here exactly? If it involves new/changed labels, ordering is not enough to do anything about this as rpm uses the context label definitions that existed when the transaction started. So in addition to somehow ordering selinux first, rpm would potentially need to learn to reload the labels in middle of transaction which has its own set of issues.
Anyway, conditional nak - we should be able to do something about this specific case, "generic fix" for the rpm <-> selinux interactions is likely to be beyond the scope of rhel-6 however.
*** Bug 784289 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > What kind of selinux policy change are we talking about here exactly? If it > involves new/changed labels, ordering is not enough to do anything about this > as rpm uses the context label definitions that existed when the transaction > started. So in addition to somehow ordering selinux first, rpm would > potentially need to learn to reload the labels in middle of transaction which > has its own set of issues. In our particular case, it is only the addition of new rules on existing labels. So the ordering would be sufficient. It does sound like OrderWithRequires: is the right answer here, but as discussed above it isn't available yet on RHEL 6. So what is the right course of action here? Breaking upgrades on SSSD is a very serious issue.
I'm still looking to hear how we can handle this in SSSD for 6.3.
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
*** Bug 820759 has been marked as a duplicate of this bug. ***
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
*** Bug 905104 has been marked as a duplicate of this bug. ***
Devel-ack for backporting the OrderWithRequires feature. The differences in the code base are not so severe as it first looked like. OTOH NACK for considering conflicts for ordering. This is a way to intrusive change with unforeseeable consequences.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Devel-ack for backporting the OrderWithRequires feature.
Pasting here the feature description, just for the record. OrderWithRequires Packages can supply extra transaction ordering hints via new OrderWithRequires tag. This follows Requires tag syntax, but does not generate actual dependencies. Only if the involved packages are present in the same transaction, the ordering hints are treated as if they were Requires when calculating the transaction order.
Fixed in rpm-4.8.0-46.el6.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1452.html