Bug 500608

Created attachment 343754 [details]
audit.log

We really shouldn't need to do a relabel after the upgrade since contexts should be getting preserved.

Can you boot into single-user mode and do a restorecon and attach a log of what got relabeled?  It might just be a directory or two we need to verify.

Matt did the selinux policy successfully upgrade?  What selinux-policy version was this.  We believe we have fixed the problems with the -34 package.

dwalsh, -34 is what was installed by anaconda during the upgrade.

Jeremy, unfortunately I didn't log the results of the restorecon I ran, and it was on a tty console so I think the results are lost. :-(  A bunch of things were relabeled, though I think most of them were homedir files/dirs.

Was there any errors in the anacond log? around selinux policy?

It looks like a lot of the AVC's were fixed in the current policy.   Also did you by any change boot the old kernel?

dwalsh: no errors or other signs of failure in anaconda.log.  I did not boot the old kernel (there is only the new kernel installed, so could not have).  rpm -V shows the selinux-policy-* packages are correct on disk.

Can you attach the anaconda.log so I can see the ordering

Created attachment 343875 [details]
anaconda.log

I was unable to reproduce by doing a fresh install of F10 i386 in a KVM VM, upgrading all packages, then running preupgrade.  Not sure how my earlier failure scenario differs from this, but clearly it did.  If I'm the only person who has seen it, then it's not a blocker.  However, it's hard to know, as preupgrade has been broken for weeks, and is only now working when using an updates disk:
https://bugzilla.redhat.com/show_bug.cgi?id=499321

I've spent some time today trying to reproduce and haven't with a few different scenarios.  The only thing I can think of is a) policy package fix in the mean time or b) something was incorrectly labeled before the upgrade began and it just was made enough worse afterwards to prevent booting

Since policy versions match, I'm leaning towards b.  I'll leave open for now to see if anyone else trips over it, but unless they do, I'm not inclined to hold up the release

Agreed on not blocking F11.  Unclear how it could have failed, as I had been booting and everything worked fine, up and until running preupgrade.  So there was little chance for the file contexts to get changed to be incorrect.

The way policy updating currently works, this is a selinux-policy bug.

selinux-policy-targeted %post is supposed to handle the relabeling automatically, and sometimes it messes up. Anaconda *could* fix that by forcing a restorecon after the upgrade but that would make upgrades take much longer, and just papers over the actual problem. It'd be better to fix the policy.

As mentioned in comment #3, selinux-policy -34 should have fixed the problem. It was tagged on May 11, which would have made it land in Rawhide on the 12th or so:
  https://fedorahosted.org/rel-eng/ticket/1776
Is it possible that your mirror still had the previous selinux-policy package at the time of your error? That would explain why it can't be reproduced now.

# rpm -q --last selinux-policy-targeted
selinux-policy-targeted-3.6.12-34.fc11        Tue 12 May 2009 08:40:57 PM EDT

# rpm -qa --last | grep -c 'Tue 12 May 2009' 
1631

So yes, -34 was upgraded along with the 1631 other packages that were part of the preupgrade-started process.  I'm not sure what I had there before (whatever was in F10 latest updates as of 12 May), but I definitely had -34 afterwards.  Before -34 was installed, the system was running fine.  After -34, the noted directory or files were mislabeled preventing hal from starting.

Matt the problem is the selinux-policy that you updated to before 34 failed.  Because of other bugs, leaving your machine in a mislabeled state.  Upgrading to -34 would not find the correct differences to relabel.

selinux policy on update does a diff between previous policy version and new and runs restorecon on the difference

rpm pseudo code

%pre
cp file_context file_context.pre

%post
rebuild selinux-policy creating a new file_context
load selinux-policy
diff file_context.pre file_context | restorecon -f -

The problem is the previous -28 upgrade blew up but completed the install of the new file context without running the restorecon.  So labeling was wrong.

Then you installed -34 which diffed with -28 and found fewer differences.

OK, I'll buy that.  So not an anaconda bug, and probably not exclusively an F10 -> F11 upgrade bug, so no F11Blocker.  But can something be done in the selinux-policy package to account for such previous failures and correct them then?  Or is a relabel of the whole file system necessary to really correct it?

THe only real safe thing in that case is to fixfiles restore. I guess the pre could look to see if a fixfiles.pre exists, and if so do not replace it.  Then if the post install script blows up it will not remove the fixfiles.pre.  If a later selinux SELinux policy upgrade happens it will use the older .pre


We could also look into a quicker fixfiles restore, since we usually only care about

/usr /etc /var 

We could just restorecon on those, if we found a previous upgrade failed.

Actually this is the full list.  On my Lenova t61 laptop



time restorecon -R  /bin /boot /lib /lib64 /root /sbin /usr /var

real	4m4.268s
user	1m54.820s
sys	0m12.964s

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I added 

	   [ -f ${FILE_CONTEXT}.pre ] || cp -f ${FILE_CONTEXT} ${FILE_CONTEXT}.pre; \


To the selinux-policy pre upgrade script.  This will leave the original .pre file in place, if an upgrade has failed.  So the fixed update or the last update will get the original file_context.pre and do a diff in the post versus the file_context file.