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
Version-Release number of selected component (if applicable):
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
rhgb doesn't come up
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?
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
> 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?
This is a special case of bug 220322 I just opened. Automatic relabeling of the
file system misses the underlying directories of mount points.
Ok I marked as duplicate.
*** This bug has been marked as a duplicate of 220322 ***