On 06/11/2010 10:53 AM, Daniel P. Berrange wrote:

On Fri, Jun 11, 2010 at 10:41:50AM -0400, Stefan Berger wrote:

...

This patch adds an optional XML attribute to a nwfilter rule to give the user control over whether the rule is supposed to be using the match target or not. A rule may now look like as follows with the nomatch attribute either having value '1' or 'true' (case-insensitive).

[...] <rule action='accept' direction='in' nomatch='true'>

Having inverted boolean flags is a little wierd. Can't this be written as match=false instead ?

Ok, I'll invert the logic.

...

<tcp srcmacaddr='1:2:3:4:5:6' srcipaddr='10.1.2.3' srcipmask='32' dscp='33' srcportstart='20' srcportend='21' dstportstart='100' dstportend='1111'/> </rule> [...]

I am also extending the nwfilter schema and add this attribute to a test case.

I'm not sure I really understand what this is doing. Can you give a quick example of what the iptables command looks like, with and without the nomatch attribute set

Background: I can specify rules so that the ssh port 22 (tcp) is reachable on my system and no other traffic is possible. If I don't use the --match target on this tcp port 22 rule, I could initiate traffic inside the VM from TCP port 22 (client port) towards an allowed target. If the --match NEW, ESTABLISHED target is added on incoming traffic, I get control over directionality due to the NEW. The outgoing direction will then have --match ESTABLISHED. Since the NEW will be missing on outgoing traffic, I won't be able to initiate that traffic. In essence it's iptables -p tcp --dport 22 -j ACCEPT versus iptables -p tcp --dport 22 -m state --state NEW, ESTABLISHED

Regards, Daniel