Bug 750090

Summary:	firstboot does not relabel home directory when reusing existing one
Product:	[Fedora] Fedora	Reporter:	Michael Ekstrand <michael>
Component:	firstboot	Assignee:	Martin Gracik <mgracik>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	16	CC:	bcl, dmach, joao.m.santos.silva, mgracik
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-17 12:28:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michael Ekstrand 2011-10-30 20:08:45 UTC

Description of problem:
I installed F16 x86_64 TC on my laptop and re-used my home filesystem from my i386 F15 install. While firstboot changed the permissions and ownership on my files, it did not apply an SELinux relabel to them, so I could not log in to the resulting desktop seemingly due to SELinux denials.

Version-Release number of selected component (if applicable):
firstboot-16.4-1.fc16.x86_64

How reproducible:
Seen once out of 1 install.

Steps to Reproduce:
1. Install F16 TC with Gnome and pre-existing home filesystem from F15, SELinux enabled and enforcing.
2. Create new user with name of existing home directory 
3. Confirm "yes" to change home directory permsisions
4. Try to log in (to Gnome desktop)
  
Actual results:
Logging in results in the sad Gnome screen (something bad happened - log out), along with notification of at least one AVC denial.

Running `restorecon -Rv` on my home directory updated SELinux contexts on a large number of files, suggesting to me that the problem is that the permission update didn't restore SELinux contexts, *even though the confirmation screen suggested that it would*.

Expected results:
Login and application work, files are properly labeled.

Additional info:

Comment 1 Martin Gracik 2011-11-10 07:19:21 UTC

*** Bug 752555 has been marked as a duplicate of this bug. ***