[refpolicy] Milter Mail Filters
paul at city-fan.org
Fri Oct 10 13:24:09 CDT 2008
On Wed, 8 Oct 2008 15:22:25 -0400
"Christopher J. PeBenito" <cpebenito at tresys.com> 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
> > 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
How to proceed with this?
More information about the refpolicy