From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 23 Nov 2009 10:19:21 -0500
Subject: [refpolicy] services_nut.patch
In-Reply-To: <1258987001.3109.6.camel@localhost>
References: <4AFC823D.3090202@redhat.com>
	<1258381900.5120.16.camel@localhost>  <4B019ACD.4010406@redhat.com>
	<1258901980.2423.16.camel@localhost>  <4B0A88B7.1050903@redhat.com>
	<1258987001.3109.6.camel@localhost>
Message-ID: <1258989561.27504.643.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2009-11-23 at 15:36 +0100, Stefan Schulze Frielinghaus wrote:
> On Mon, 2009-11-23 at 14:05 +0100, Miroslav Grepl wrote:
> [...]
> > > Another question, what is the intention of the following
> > >
> > > permissive upsd_t;
> > > permissive upsdrvctl_t;
> > > permissive upsmon_t;
> > >
> > > Does that make the domain permissive by default?
> > Yes, it does. We add new domains to permissive so we can fix all the avc's without blocking of functionality apps.
> 
> But not for refpolicy, right? I cannot find any such statement in the
> policy modules of refpolicy. At least I wouldn't expect such a behavior
> from modules of refpolicy. I guess we can remove those three lines.
> 
> If you are fine with the merge of both policies then we can commit it
> (after the port change of course).

My policy is to not have permissive domains in upstream refpolicy.  If
the modules need more work the patch is dropped.  Otherwise the
permissive is dropped.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150