[prev in list] [next in list] [prev in thread] [next in thread]
List: refpolicy
Subject: [refpolicy] services_nut.patch
From: mgrepl () redhat ! com (Miroslav Grepl)
Date: 2009-11-23 17:17:37
Message-ID: 4B0AC3B1.20003 () redhat ! com
[Download RAW message or body]
On 11/23/2009 05:09 PM, Stefan Schulze Frielinghaus wrote:
> On Mon, 2009-11-23 at 17:04 +0100, Stefan Schulze Frielinghaus wrote:
>
> > On Mon, 2009-11-23 at 10:19 -0500, Christopher J. PeBenito wrote:
> >
> > > 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?
Yes, I meant in Fedora.
> > > > 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.
> > >
> > Yes, this is what I thought. Since I use the NUT policy for about a year
> > and it has some intersection with Miroslavs policy (he uses NUT with a
> > ups attached via USB and my via SNMP), I would say it is stable enough.
> >
> Just to make it precise. In general it is stable but I will wait for an
> OK from Miroslav,
I will check it and let you know.
> then I'm going to rearrange some allow rules according
> to the style-guidelines and will submit the patch again.
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic