Date: Tue, 14 Dec 2004 16:07:12 +0300 From: Gleb Smirnoff <glebius@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: Max Laier <max@love2party.net> Subject: Re: per-interface packet filters [summary] Message-ID: <20041214130712.GA46386@cell.sick.ru> In-Reply-To: <41BEE0E7.BD2316EB@freebsd.org> References: <20041213124051.GB32719@cell.sick.ru> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214130712.GA46386>