Bug 746448 - SELinux policy crashes Gnome-Shell
Summary: SELinux policy crashes Gnome-Shell
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-16 01:38 UTC by yach
Modified: 2011-10-17 18:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-17 18:29:59 UTC
Type: ---


Attachments (Terms of Use)
sealert troubleshoot screenshot (37.75 KB, image/png)
2011-10-16 01:38 UTC, yach
no flags Details

Description yach 2011-10-16 01:38:38 UTC
Created attachment 528356 [details]
sealert troubleshoot screenshot

Description of problem:
SELinux prevents Gnome-Shell from loading correctly on Fedora 16 nightly up to date.


Version-Release number of selected component [selinux-policy] (if applicable):
Version : 3.10.0
Révision : 40.fc16

How reproducible:
Every time.

Steps to Reproduce:
1. Boot up.
2. GDM login to gnome 3 session.
  
Actual results:
Gnome-Shell stalls a bit, then displays the panel and displays the "Oh no ! Something has gone wrong" error message. The system is responsive (can reveal the dash), but not usable (can't click anywhere).

Expected results:
Gnome-Shell usable.

Additional info: it's probably linked to selinux-policy, as some error messages are displayed by sealert (see attached document).
Console login through alt+f2 works, but there is something wrong too here, as the [ -- user : /home/user : change directory failed : Premission denied. Logging in with home = "/" ] message is displayed.
Both problems (gnome-shell crash and console login warning message) can be worked around by typing in "sudo setenforce Permissive".

Setting severity to "high" even if there is a workaround, because it's not very easy to use.

Comment 1 yach 2011-10-16 16:58:43 UTC
Hmmm, I was able to solve this issue for good with the solution given on bug #739326 (restorecon -R -v ~/.local).
However, I'm leaving that bug open as this should already be fixed, if I'm not wrong. Feel free to correct if I am :-)

Note : I installed Fedora 16 with custom layout, and didn't erase my home directory (but I did format the root filesystem).

Comment 2 Miroslav Grepl 2011-10-17 07:28:39 UTC
I would say the problem is your ~/.local was mislabeled before an update but this mislabeling did not cause any issues.

Actually,
could you execute

# restorecon -R -v ~/

Comment 3 yach 2011-10-17 18:00:46 UTC
Should I do this as root ? (as the # before the command line suggests) ?
Anyway, restorecon -R - v ~/.local did the trick, so what should I be expecting from restorecon -R -v ~/ ?

And shoudln't the update process fix those kind of things ? I'm only asking, I don't know anything about SElinux tbh.

Thanks for your answer and for your time.

Comment 4 Daniel Walsh 2011-10-17 18:29:59 UTC
Well we don't want to random run restorecon on the users homedir.  There are tools in F16 that check if the labeling is correct and creates the content with the correct label, but on update we do not search for all mislabeled files especially in the users homedir.


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