Bug 577911
| Summary: | Some selinux contexts get spontaneously changed on every reboot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alex Villacís Lasso <alexvillacislasso> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | anton, dougsland, dwalsh, eparis, gansalmon, itamar, jmorris, jonathan, kernel-maint, mgrepl, sdsmall |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-03-30 15:11:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Alex Villacís Lasso
2010-03-29 17:05:13 UTC
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 2.6.34-rc2 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 2.6.32.9-70.fc12.x86_64
Created attachment 403365 [details]
Result of restorecon run after second boot with 2.6.32.9-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 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=de329820e920cd9cfbc2127cad26a37026260cce 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 and 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. http://koji.fedoraproject.org/koji/buildinfo?buildID=164438 |