Bug 1801087
Summary: | colord fails to start due to selinux | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Mach <dmach> |
Component: | colord | Assignee: | Richard Hughes <rhughes> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 32 | CC: | bugzilla, fzatlouk, gnome-sig, lruzicka, mcatanza, rhughes, robatino, zpytela |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | AcceptedBlocker | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-03-06 18:54:12 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1705305 |
Description
Daniel Mach
2020-02-10 08:47:52 UTC
Proposed as a Blocker and Freeze Exception for 32-final by Fedora user lruzicka using the blocker tracking app because: There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop. Discussed during the 2020-02-10 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present" [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-02-10/f32-blocker-review.2020-02-10-17.01.log.txt This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. [ 14.983762] fmac.local audit[1442]: AVC avc: denied { setsched } for pid=1442 comm="colord" scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:colord_t:s0 tclass=process permissive=1 selinux-policy-3.14.5-28.fc32.noarch Is this related to bug 1795524? This is also selinux setsched related according to the AVC denial. Chris, it looks so. https://bugzilla.redhat.com/show_bug.cgi?id=1795524#c84 selinux will continue to deny setsched, so a fix is still needed in colord. Other daemons are affected, but I'm not sure whether there's a generic solution possible. We're not going to change GThreadPool to stop trying to use setsched, but GThreadPool has been fixed to at least not abort. Nothing about this issue is unique to colord, other than that SELinux seems to be allowing some apps to use setsched but not others. *** This bug has been marked as a duplicate of bug 1795524 *** BTW the abort on failure to call setsched() should be fixed since GLib 2.63.4, which should have hit F32 quite a while ago. If colord is still failing to launch nowadays, then you can reopen this issue (as if so, there must be multiple bugs involved). |