Bug 217286

Summary:	selinux prevents rhgb from running
Product:	[Fedora] Fedora	Reporter:	Tobias Oed <tobiasoed>
Component:	selinux-policy	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED DUPLICATE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	rstrode
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:	2007-02-14 18:36:12 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:

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
/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:

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?
Tobias

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?
Tobias.

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.

Tobias

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 ***