From: dwalsh@redhat.com (Daniel J Walsh)
Date: Tue, 16 Feb 2010 12:26:39 -0500
Subject: [refpolicy] system_unconfined.patch
In-Reply-To: <1266328452.11004.48.camel@gorn.columbia.tresys.com>
References: <4AFC8970.5080708@redhat.com>	
	<1266005836.11004.30.camel@gorn.columbia.tresys.com>	
	<4B7698A7.2080404@redhat.com>
	<1266328452.11004.48.camel@gorn.columbia.tresys.com>
Message-ID: <4B7AD54F.3050008@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 02/16/2010 08:54 AM, Christopher J. PeBenito wrote:
> On Sat, 2010-02-13 at 07:18 -0500, Daniel J Walsh wrote:
>> On 02/12/2010 03:17 PM, Christopher J. PeBenito wrote:
>>> On Thu, 2009-11-12 at 17:17 -0500, Daniel J Walsh wrote:
>>>> http://people.fedoraproject.org/~dwalsh/SELinux/F12/system_unconfined.patch
>>>>
>>>> Split out unconfined_t from unconfined_domain.
>>>
>>> I don't know if this will ever be upstreamable in a fashion you like.
>>> My understanding is that you want to be able to have the unconfined_t
>>> domain loaded without the unconfined_domain module loaded, so
>>> unconfined_t is the only unconfined domain.  To be acceptable for
>>> upstreaming, the unconfined role would have to unconditionally depend on
>>> the unconfined domain module, which wouldn't allow you want.
>>>
>> I don't understand your statement here.  You are saying that we can't
>> upstream this because it is impossible, and yet it works for me.
> 
> I didn't mean that its technically impossible.  It breaks concepts in
> refpolicy.  The concept of an unconfined domain resides in the
> unconfined module.  Remove the unconfined module, then there is no
> concept of unconfined domains; thus, there cannot be an unconfined user
> domain.
> 
Well then maybe we need an unconfineduser and unconfinedsystem policy package and you could choose to remove one or the other or remove unconfined and they all disappear.