Bug 490323 - SELinux is preventing gpm (gpm_t) "read" etc_t.
SELinux is preventing gpm (gpm_t) "read" etc_t.
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
Reported: 2009-03-15 06:54 EDT by Michael Monreal
Modified: 2009-05-06 16:24 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-06 16:24:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Log (2.33 KB, text/plain)
2009-03-15 06:54 EDT, Michael Monreal
no flags Details
Patch to run restorecon after creating /etc/localtime (1.18 KB, patch)
2009-03-18 11:16 EDT, Daniel Walsh
no flags Details | Diff

  None (edit)
Description Michael Monreal 2009-03-15 06:54:11 EDT
I just got this SElinux warning which asks to file a bug. I will attach the complete log.
Comment 1 Michael Monreal 2009-03-15 06:54:41 EDT
Created attachment 335245 [details]
Comment 2 Zdenek Prikryl 2009-03-17 04:10:05 EDT
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.
Comment 3 Daniel Walsh 2009-03-17 13:33:15 EDT
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.
Comment 4 Michael Monreal 2009-03-18 08:08:31 EDT
(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.
Comment 5 Daniel Walsh 2009-03-18 09:01:26 EDT
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
Comment 6 Chris Lumens 2009-03-18 10:47:05 EDT
/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.
Comment 7 Michael Monreal 2009-03-18 11:03:57 EDT
Oh, firstboot != anaconda? Well, I definitively used firstboot.
Comment 8 Daniel Walsh 2009-03-18 11:16:36 EDT
Created attachment 335713 [details]
Patch to run restorecon after creating /etc/localtime
Comment 9 Nils Philippsen 2009-04-20 04:39:00 EDT
Thanks for the patch, version 1.9.38 which contains it is building right now.
Comment 10 Will Woods 2009-05-06 16:24:09 EDT
system-config-date-1.9.38-1.fc11 is in Rawhide.

Note You need to log in before you can comment on or make changes to this bug.