About matching (also was: Multiple Targets)

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Jonas Berlin on 2005-04-14 13:21 UTC:

>>>All which is technically required for this while keeping full binary
>>>copatibility is to modify non-terminal targets to register themselves as
>>>matches in addition to targets.
> 
> Does iptables have any requirement that matches have to be lowercase?

It seemed not.

>>>The only thing holding this back is a conceptual design question if you
>>>should be allowed to mix non-terminal targets and matches freely, but
>>>this can be addressed in userspace if desired to force all non-terminal
>>>targets last in the match list.
> 
> I think the return values of targets used as matches should verified to
> be IPT_CONTINUE (or whatever it was called) and syslog messages written
> if that wasn't the case. In either case, the return value would not be
> used for anything else..

As a first test, I tested with the LOG target, since that's what people
mostly ask for :)

What I did was I made LOG register itself as both a target and a match.
I kept the name in uppercase which avoided creating new modules.

So this is how it works (I have tested it quickly):

  iptables -A OUTPUT [...] -m LOG --log-prefix "wohoo" -j ACCEPT

instead of:

  iptables -A OUTPUT [...] -j LOG --log-prefix "wohoo"
  iptables -A OUTPUT [...] -j ACCEPT


Alternative implementations:

a) Do you think my idea of updating each potential target with match
code is ok, or

b) should maybe iptables automatically let one use any non-builtin
target as a match directly, or

c) same as b) but instead only let one use targets that have a special
flag set in their ipt_target structure, or

d) same as c) but instead add another struct ipt_match_target interface
(and accompanying register_match_target()) that have modified function
prototypes with only arguments common to both matches and targets..

pros & cons:

a) is trivial to implement and error-prone due to its mechanical nature.
However it doesn't require any changes to the generic netfilter code.

b) unfortunately lets one use targets that are not suitable as matches,
but lets one use any target without updating all targets that could be
used as matches.

c) requires minimal updates to the targets that are suitable (adding one
line), but might be a bit hacky since it would convert match arguments
to target arguments and possibly not all arguments can be given sane
values..

d) requires more modification to the individual targets than c) but less
than a) and does not clutter the source code of the targets like a) does.

To make it clear, the patches attached are implemented according to a).

I would go for a) or d)..

> I will be away until next Monday, but if you still haven't started
> implementing this by then, I will probably give it a shot :) Otoh I

I took my time but here it is :)

Comments, please :)

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCeA3ixyF48ZTvn+4RAndpAJwJ8eQMOWdtwunqTXhOv/eJ8C1GnQCgrKYz
b3gX3rOJEtpkVzMs92zT3RE=
=oiRA
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LOG-match-iptables.diff
Type: text/x-patch
Size: 4290 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20050503/f9071f0a/LOG-match-iptables-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LOG-match-linux-2.6.diff
Type: text/x-patch
Size: 3941 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20050503/f9071f0a/LOG-match-linux-2.6-0001.bin