Description of problem: I restored my / partition from backup. Since the backup had no selinux labels in it I had to force a relabel of the whole file system (touch /.autorelabel, reboot), which fixed everything but rhgb. The problem is that even after the relabel ls -Zd /etc/rhgb/temp gave drwxr-xr-x root root system_u:object_r:file_t /etc/rhgb/temp restorecon /etc/rhgb/temp changes that to drwxr-xr-x root root system_u:object_r:mnt_t:s0 /etc/rhgb/temp/ and rhgb works again. With the wrong labels, rhgb fails so early that there is no logging facility running yet and no trace of anything in /var/log/messages or /var/log/audit/audit.log Version-Release number of selected component (if applicable): rhgb-0.16.4-3.fc6 selinux-policy-targeted-2.4.3-10.fc6 selinux-policy-2.4.3-10.fc6 How reproducible: Probably 100%, but I'm not sure and not going to try. Steps to Reproduce: 1. modify the security context of /etc/rhgb/temp to system_u:object_r:file_t 2. touch /.autorelabel 3. reboot Actual results: rhgb doesn't come up Expected results: rhgb works Additional info:
Did you do the restorecon after updating grabbing the latest packages from -updates?
I did the backup/resotre in a 'linux rescue' session from the fc6 dvd a couple of hours before reporting the bug. That was on saturday nov 24th because. (I had to modify my partitioning scheme somewhat). yum.log tells me that the relevant packages are older than that Nov 03 22:03:14 Updated: rhgb.i386 0.16.4-3.fc6 Nov 20 18:32:19 Updated: selinux-policy.noarch 2.4.3-10.fc6 Nov 20 18:37:01 Updated: selinux-policy-targeted.noarch 2.4.3-10.fc6 Here are some more bits of information that may turn out to be important: I remember that rhgb worked right after the resotre, but I couldn't log in because of the misslabeling. So I 'linux rescued' again to touch the autorelabel and autorelabeling happened with a working rhgb. Now, rhgb uses /etc/rhgb/temp as a mount point for it's ramfs. So maybe autorelabel missed the file because the ramfs was mounted on top of it? Tobias
So is it working correcly now on reboot? How is the /etc/rhgb/temp mounted?
> So is it working correcly now on reboot? I got it to work with a manual restorecon /etc/rhgb/temp when nothing was mounted there. > How is the /etc/rhgb/temp mounted? /etc/rc.d/rc.sysinit starts rhgb and rhgb mounts a ramfs on /etc/rhgb/temp like so: src/main.c:434: if (mount("none", TMPPATH, "ramfs", 0, "maxsize=512")) Later /etc/rc.d/rc.sysinit starts the relabeling with rhgb still running so the ramfs is still mounted at /etc/rhgb/temp and restorecon misses the relabeling of the underlying file (I think). Do I make sense? Tobias.
This is a special case of bug 220322 I just opened. Automatic relabeling of the file system misses the underlying directories of mount points. Tobias
Ok I marked as duplicate. *** This bug has been marked as a duplicate of 220322 ***