Created attachment 403326 [details]
Sample run of restorecon that shows messed-up contexts that were restored
Description of problem:
After installing the latest selinux-policy-* for Fedora 12, I have noticed that some random SELinux contexts get changed on files on every reboot. This results in random problems arising from denial of access to system files or directories, or denied capabilities.
Some of the symptoms I have experienced so far (not all at the same time):
Failure to start auditd daemon (denied access to /var/log/audit/audit.log)
Failure to start nmb daemon (denied access to /var/lib/samba/browse.dat*)
Failure to start gdm and graphic session (denied access to /etc/group)
Failure to determine hostname on apache/sendmail/cups (denied access to /etc/hosts)
I have found the following workaround: log in text console as root, and run restorecon -r on the entire filesystem. This restores a bunch of changed contexts, but only works until the next reboot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install mentioned versions of packages
2.Reboot (several times if necessary)
3.Monitor boot process and contexts
File contexts get changed on reboot on a seemingly random way, and cause various symptoms arising from denied access to various system components.
No spontaneous changes to selinux contexts on reboot
This problem might explain the following bugs:
None of these bugs are caused by labeling problems, I believe. Although 577890 could be.
Are you seeing the above attachment of bad context on each reboot? Or was this run from the first time?
Any chance you were using livecd or mock?
running kernel version (uname -r)?
filesystem type? (cat /proc/mounts)
The attached report is from my work machine.
I use my work machine (normally left on all night) to download the Fedora updates, apply them on the work days, and batch them all to apply them to my home machine (shut down every night) on weekends. I have been running kernel 2.6.34-rc2 on both home and work. I have been seeing this labeling problem on my work machine since I updated selinux-policy-* on March 23-24. Right after rebooting my machine, I got the /etc/group denial problem. I applied restorecon /etc/group to be able to work again. My home machine did not experience labeling problems until I applied the batch of updates from my work machine, which included selinux-policy-*. I must note that I do not suspect the custom kernel to be at fault, since my home machine ran it just fine before the updates.
On work machine:
rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,seclabel,relatime 0 0
udev /dev tmpfs rw,seclabel,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
/dev/sda2 / ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
none /selinux selinuxfs rw,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda1 /boot ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
/dev/sda5 /home ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
gvfs-fuse-daemon /home/alex/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0
Both work and home machine are previously-working Fedora 12 x86_64 machines, installed into hard disk.
The attached restorecon report was generated today (March 29) at my work machine.
I had seen some problems with kernel
Could you try to boot with the f12 kernel. Fix the labels and then reboot, and see if the labels are screwed up.
I was playing around with this kernel also, but simultaneosly with livecd and mock, I blamed them for screwing up the labels, but it could very well be the kernel. I booted F13 kernel and the labels are not getting mixed up.
Now I can't get it to happen with that kernel. I will install fc2 and try livecd-creator again.
Created attachment 403364 [details]
Result of restorecon run after first boot with 22.214.171.124-70.fc12.x86_64
Created attachment 403365 [details]
Result of restorecon run after second boot with 126.96.36.199-70.fc12.x86_64
As requested, I fixed the labels after a boot with the fc12 kernel, then rebooted again to check what happened. A bunch of labels were restored after the first boot. Just two were restored at the second boot. However, I am not entirely convinced that this is a kernel problem. The restorecon after the second boot shows two files that were supposed to be already fixed in the first restorecon.
A separate reporter seems to have found a problem with how ext3 is handling things in 2.6.34 and reports that fixing that issue made the random labels go away. Believing it to be a 2.6.34 kernel problem also explains why you didn't have the craziness on the 32 kernel (the xorg lock one is normal, but I don't know what backuppc is doing, it could be normal as well)
As soon as I have a public posting to a patch I'll notate it here. For now it looks like an issue with commit 9df93939b73
Fix is committed in Linus's tree
Why don't you give a kernel with that patch a try and tell us what you see. Thanks for the report!
restorecon reset /etc/BackupPC/pc context system_u:object_r:httpd_sys_content_rw_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0
restorecon reset /tmp/.X0-lock context system_u:object_r:xdm_tmp_t:s0->system_u:object_r:xserver_tmp_t:s0
httpd_sys_content_rw_t == httpd_sys_script_rw_t
xdm_tmp_t == xserver_tmp_t
They are aliases of each other in policy.
Sadly restorecon has no way of knowing this.
I will fix the labeling in policy.
/etc/BackupPC/pc is provided in the BackupPC package, so I can not fix that one.
In reality the labelling is correct.
Fixed in latest F14 kernels.