From: dominick.grift@gmail.com (Dominick Grift)
Date: Tue, 07 Aug 2012 22:27:00 +0200
Subject: [refpolicy] [PATCH v4]: mcelog module initial rewrite
In-Reply-To: <50217898.1000106@trentalancia.com>
References: <201208061519.q76FJcDp011962@vivaldi31.register.it>
	<1344267046.29329.57.camel@d30.localdomain>
	<50201053.9000506@trentalancia.com>
	<1344282251.29329.73.camel@d30.localdomain>
	<50215188.7040900@trentalancia.com>
	<1344361404.2306.5.camel@d30.localdomain>
	<50216DFF.1050309@trentalancia.com>
	<1344368916.2306.14.camel@d30.localdomain>
	<50217898.1000106@trentalancia.com>
Message-ID: <1344371220.2306.18.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Tue, 2012-08-07 at 22:20 +0200, Guido Trentalancia wrote:

> >
> > allow mcslog_t self:unix_stream_socket { create_socket_perms
> > connectto; }
> 
> Yes, I think it can be done, but I would need to check. But is this not 
> going to be considered overengineering ?

No that is the way to go

> I don't like such term very much in this context anyway, as usually 
> there is always an advantage in terms of maintanability.
> 
> > or show me the avc denials related to mcelog_t operating on mcelog_t
> > unix stream sockets so that we can figure out the exact permissions.
> >
> > but using stream_connect_pattern() is not the way to go here
> 
> Initially you had suggested that pattern, so I went for that.

Right but at that time i didnt see the big picture (context of the
usage)