per-interface packet filters [summary]

[Gleb Smirnoff]

On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
A> > Implementationwise, the kernel side is evidently trivial as the
A> > original code already supports the idea of multiple chains.  All
A> > you need is to extend the struct ifnet with a pointer to the chain,
A> > or use some other trick (e.g. going through ifindex) to quickly
A> > associate a chain to the input (and possibly output) interface.
A> 
A> Nonononononononononononononononononononononono.
A> 
A> There MUST NOT be any firewall specific pointers or other information
A> in struct ifnet or any other non-firewall private part of the kernel.
A> Otherwise the entire independence we've gained with the nice and clean
A> PFIL_HOOKS API goes down the drain.  This MUST NOT happen again.
A> 
A> The whole idea of the PFIL_HOOKS is to have independend and loadable
A> firewall modules with different approaches, internal designs and so
A> on.

The whole idea of PFIL_HOOKS is to have independend and loadable firewall
modules, which can be attached to different parts of kernel! There is no
such requirement that, pfil hooks MUST be sticked to a single entry point
in ip_input() and ip_output().

Pfils attached to interface belong to interface, and thus should be stored
in struct ifnet. This is the way it is done in per-interface filters.

A> For example a way Gleb can get his way without any bickering from us
A> is by creating his own gleb-firewall module using the PFIL_HOOKS API
A> and put it into the ports tree for easy access, provided he doesn't
A> modify the PFIL_HOOKS API (which he doesn't have to).

I am not going to create a new firewall or change PFIL_HOOKS. I'm going
to attach *the existing* pfil_hooks to a different place, to perform
filtering with *existing* firewalls.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE