Bug 430600 – <sys-apps/openrc-0.10 mounts rc-svcdir as tmpfs AND ramfs

• Product: Gentoo Hosted Projects
• Status: RESOLVED TEST-REQUEST

[Description Alex Brandt (RETIRED) 2012-08-09 13:52:55 UTC]

When using <openrc-0.10 I get a mounted system like the following:

rc-svcdir on /lib64/rc/init.d type tmpfs (rw,rootcontext=system_u:object_r:initrc_state_t,seclabel,nosuid,nodev,noexec,relatime,size=1024k,mode=755)
rc-svcdir on /lib64/rc/init.d type ramfs (rw,nosuid,nodev,noexec,relatime)

The ramfs overlays the tmpfs (causing the selinux context to be lost).  It looks like it's because the /lib64/rc/sh/init.sh script gets run twice for some reason and the logic is setup so that if there is a problem mounting tmpfs (which there will be the second time due to already being mounted); the fall through logic mounts a ramfs on top of the previous location.

I've asked around and looked at other systems to try and verify this but have only verified it on xenU rc_sys types (xen guests).

Reproducible: Always

Steps to Reproduce:
1.emerge \<openrc-0.10
2.reboot
3.mount | grep rc-svcdir | wc -l
Actual Results:  
The above will provide two lines (for sure on a xenU system).

Expected Results:  
The above should provide one line, <openrc-0.10, and zero lines for >=openrc-0.10

Again, I believe this is only when specifying the rc_sys="xenU" but haven't been able to prove this to myself.  The critical piece of this and the only reason I found it is because this breaks the selinux contexts and certain RC events start getting denied by selinux with this behavior.

[Comment 1 William Hubbs 2012-08-17 18:44:30 UTC]

Please test and re-open if this is an issue with >=openrc-0.10.

Thanks much.

[Comment 2 Alex Brandt (RETIRED) 2012-08-17 20:29:04 UTC]

I've already tested with >=openrc-0.10 and there are no problems but at the sametime there was and is no stable openrc other than 0.9.8.4.  Is there a stabilization of any >=openrc-0.10 coming soon to solve this bug?