From: dominick.grift@gmail.com (Dominick Grift)
Date: Tue, 14 Jan 2014 15:02:08 +0100
Subject: [refpolicy] RFC: direct_init_entry breaks direct_initrc
In-Reply-To: <52D54215.3040707@tresys.com>
References: <1386691021.18689.75.camel@d30> <52D54215.3040707@tresys.com>
Message-ID: <1389708128.28251.54.camel@x220.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 2014-01-14 at 08:56 -0500, Christopher J. PeBenito wrote:
> On 12/10/13 10:57, Dominick Grift wrote:
> > I have not tested this yet and it is a theory
> > 
> > I was not there when that type attribute was implemented so i do not
> > know the rationale behind the decision to implement it.
> > 
> > Would be nice if anyone could shed some light on that and would be even
> > better if this fix is acknowledged
> 
> It seems like it would probably work, but definitely needs to be tested.
> 

I have tested it. role transitions should happen on the init script and
now on the daemon entry file. This is a bug in the init_run_daemon
interface and it breaks a lot of stuff

Also the init_run_daemon(unconfined_t, unconfined_r) should be make
tunable (direct_sysadm_daemon)

Removing the init_run_daemon(unconfined_t, unconfined_r) like fedora did
does not solve anything in any sustainable way.

I doubt that unconfined_t role transitions at all without that interface
call so you'd end up with: unconfined_u:unconfined_r:daemon_t instead of
unconfined_u:system_r:daemon_t