Bug 490323
| Summary: | SELinux is preventing gpm (gpm_t) "read" etc_t. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Monreal <michael.monreal> | ||||||
| Component: | system-config-date | Assignee: | Nils Philippsen <nphilipp> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | CC: | dwalsh, mgrepl, nphilipp, pertusus, rmaximo, vanmeeuwen+fedora, wwoods, zprikryl | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-05-06 20:24:09 UTC | Type: | --- | ||||||
| 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: | 446452 | ||||||||
| Attachments: |
|
||||||||
|
Description
Michael Monreal
2009-03-15 10:54:11 UTC
Created attachment 335245 [details]
Log
hmm, with gpm-1.20.6-2.fc11 and selinux-policy-3.5.13-47.fc10 everything works fine. So, it can be a bug in selinux-policy. Reassigning the bug to selinux-policy package, maintainers can take a look at it and write their opinion. The problem here is /etc/localtime is mislabeled. restorecon /etc/localtime Should fix the problem. How did /etc/localtime get created? What ever is creating it needs to execute restorecon when it completes. Sadly the kernel did not give setroubleshoot the full path so it was not able to check the labeling of /etc/localtime. (In reply to comment #3) > How did /etc/localtime get created? What ever is creating it needs to execute > restorecon when it completes. As this is a new installation I'm quite sure Anaconda must have created it... at least I did never change anything clock/date/timezone related after installation. Chris can you check if /etc/localtime has the correct context after a fresh install? ls -Z /etc/localtime Should be # matchpathcon /etc/localtime /etc/localtime system_u:object_r:locale_t:s0 /etc/localtime definitely has the right context both immediately after an install and after rebooting, though I did not run through firstboot. I wonder if system-config-date copied over a new /etc/localtime and the context did not get set properly somehow. Oh, firstboot != anaconda? Well, I definitively used firstboot. Created attachment 335713 [details]
Patch to run restorecon after creating /etc/localtime
Thanks for the patch, version 1.9.38 which contains it is building right now. system-config-date-1.9.38-1.fc11 is in Rawhide. |