From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 20 Sep 2011 10:00:50 -0400
Subject: [refpolicy] Best approach for adding inet socket support for
 milters?
In-Reply-To: <4E7208EF.8040900@city-fan.org>
References: <4E6E1933.1030100@city-fan.org> <4E70B8C8.6000608@tresys.com>
	<4E70D60F.5090705@tresys.com> <4E7208EF.8040900@city-fan.org>
Message-ID: <4E789C92.7060006@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 09/15/11 10:17, Paul Howarth wrote:
> On 09/14/2011 05:27 PM, Christopher J. PeBenito wrote:
>> On 09/14/11 10:23, Christopher J. PeBenito wrote:
>>> On 09/12/11 10:37, Paul Howarth wrote:
>>>> I'd rather return to my original suggestion of having a milter_port_t be
>>>> supported out of the box and then let admins use semanage to define any
>>>> ports they wanted to use as milter_port_t.
>>>
>>> This is fine.  I can't remember if I originally rejected this (I'm guessing I did), but I'm fine with it now.  We already have examples of this, eg, stunnel.  We should look into augmenting the corenetwork infrastructure so that the network_port() macro can handle no defined ports, so that interfaces for the type will be created.  I believe this already works for the interface generation, but the te side needs to be tweaked to not emit an incomplete portcon statement.
>>
>> This ended up being straightforward.  I updated corenetwork so that it supports defining a port type without labeling any specific ports.  That'll get the interfaces generated so we can write policy correctly (look at the contrib commit if you're not sure what I mean).
> 
> OK, here's two patches, one for corenetwork to add milter_port_t, and another for milter to use milter_port_t.

Merged.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com