Bug 217286 - selinux prevents rhgb from running
Summary: selinux prevents rhgb from running
Status: CLOSED DUPLICATE of bug 220322
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
(Show other bugs)
Version: 6
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-26 14:57 UTC by Tobias Oed
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-14 18:36:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Tobias Oed 2006-11-26 14:57:29 UTC
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):

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:

Comment 1 Ray Strode [halfline] 2006-11-27 02:56:09 UTC
Did you do the restorecon after updating grabbing the latest packages from -updates?

Comment 2 Tobias Oed 2006-11-27 10:15:48 UTC
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?

Comment 3 Daniel Walsh 2006-11-27 17:08:35 UTC
So is it working correcly now on reboot?

How is the /etc/rhgb/temp mounted?

Comment 4 Tobias Oed 2006-11-27 18:13:12 UTC
> 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?

Comment 5 Tobias Oed 2006-12-20 13:49:43 UTC
This is a special case of bug 220322 I just opened. Automatic relabeling of the
file system misses the underlying directories of mount points.


Comment 6 Daniel Walsh 2007-02-14 18:36:12 UTC
Ok I marked as duplicate.

*** This bug has been marked as a duplicate of 220322 ***

Note You need to log in before you can comment on or make changes to this bug.