From: paul@city-fan.org (Paul Howarth) Date: Mon, 17 Nov 2008 15:05:42 +0000 Subject: [refpolicy] Milter Mail Filters In-Reply-To: <1226676384.24358.78.camel@gorn.columbia.tresys.com> References: <484D4B53.5020006@city-fan.org> <1216385922.21191.125.camel@gorn> <48982587.30605@city-fan.org> <1220621188.28287.79.camel@gorn.columbia.tresys.com> <48C6A124.7090707@city-fan.org> <48D78F39.3040801@city-fan.org> <1223302377.2165.5.camel@gorn> <48ECB037.2070203@city-fan.org> <1223493745.2165.113.camel@gorn.columbia.tresys.com> <20081010192409.0a76e299@metropolis.intra.city-fan.org> <1225984176.12285.15.camel@gorn.columbia.tresys.com> <49130C17.8050208@city-fan.org> <1226676384.24358.78.camel@gorn.columbia.tresys.com> Message-ID: <49218846.7060305@city-fan.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Christopher J. PeBenito wrote: > On Thu, 2008-11-06 at 15:24 +0000, Paul Howarth wrote: >> Christopher J. PeBenito wrote: >>> On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote: >>>> On Wed, 8 Oct 2008 15:22:25 -0400 >>>> "Christopher J. PeBenito" wrote: >>>> >>>>> Moving to refpolicy list. >>>>> >>>>> On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote: >>>>>> Christopher J. PeBenito wrote: >>>>>>> On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote: >>>>>>>> Updated patch: sendmail, when run as "newaliases", tries to >>>>>>>> getattr() milter sockets as well as the directories they live >>>>>>>> in, so I changed the >>>>>>>> milter_getattr_all_data_dirs interface to >>>>>>>> milter_getattr_all_sockets. >>>>>>>> >>>>>>>> I also moved the call to this interface in mta.te out from the >>>>>>>> middle of >>>>>>>> a bunch of postfix-related lines. >>>>>>>> >>>>>>>> Paul. >>>>>>> I think my last two comments are >>>>>>> >>>>>>> * you can't require milter_port_t. It doesn't seem like a >>>>>>> generic port type would be useful anyway, otherwise there would >>>>>>> be a port defined. >>>>>> So I should change "allow milter_$1_t milter_port_t:tcp_socket >>>>>> name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"? >>>>> No. I don't see how it makes sense to have a port type common to all >>>>> milters. >>>>> >>>>>> I can do that but I don't understand why milter_port_t should be >>>>>> any different than say stunnel_port_t, which also doesn't have a >>>>>> default port defined, and would be used in a similar way, i.e. an >>>>>> admin would set up an application to use a specific port (a milter >>>>>> running over tcp needs to have a port specified, just a tunnel set >>>>>> up using stunnel does >>>>>> - they don't just bind to random generic ports). >>>>> This is not comparable, as there is only one stunnel domain, whereas >>>>> there are several milter domains. >>>> OK, I get that now, I'll use $1_milter_port_t instead then. But the >>>> question then arises: how to interface to it? You say I can't require >>>> milter_port_t and I guess that applies to $1_milter_port_t too. >>>> However, as there are no defined ports for these types, there's no >>>> expansion of network_port() for these types from corenetwork.te.in and >>>> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I >>>> got the "require milter_port_t" idea from a similar structure in the >>>> stunnel policy. >>>> >>>> How to proceed with this? >>> Sorry for the slow response; I've been consumed with the UBAC stuff. >>> >>> I'd say don't declare the port in the template and we'll add ports as >>> milters require them. >> It's not a case of one milter needing it and another not needing it; >> potentially any milter can be used in conjunction with TCP ports. The >> usual convention is to use a unix domain socket for communication >> between a milter and the MTA but the milter library supports both >> approaches, and some sysadmins may wish to configure their milters to >> use TCP sockets, so that for instance they can run the milters on >> separate hosts from the MTA in order to spread load. When they do this, >> each milter will need support in policy, which is why I included it in >> the template. > > We can't realistically support all possible configurations. At some > point we have to draw the line on trying. I think the standard > configuration that covers 80%+ of the users is a reasonable starting > point. Updated patch attached with TCP socket support removed. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: milters.patch Type: text/x-patch Size: 7099 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20081117/a83e17e2/attachment.bin