[refpolicy] Best approach for adding inet socket support for milters?

Paul Howarth paul at city-fan.org
Thu Sep 15 09:17:19 CDT 2011

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-milter_port_t.patch
Type: text/x-patch
Size: 1089 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110915/e728b2dd/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-communication-with-MTA-over-a-TCP-socket.patch
Type: text/x-patch
Size: 1105 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110915/e728b2dd/attachment-0001.bin 

More information about the refpolicy mailing list