Greetings folks, Hello, and sorry for the delayed response. Looks like this fell through
On 05/18/2011 03:10 PM, Stephen O'Dor wrote: the cracks, because it wasn't in traditional 'git format-patch' style.
I've patched the libvirt iptables interface to append it's REJECT rules rather than insert at the head. Idea being that I'm not the only person who usually puts the REJECTs at the end of a chain.
In my particular case any custom ACCEPT rules involving the bridge interfaces would get pushed below the rules that libvirt puts in to REJECT everything on the bridge interface.
I'm using the routed network mode, I have no idea if this hurts any other network mode. Stefan is probably the best person to comment on whether this makes sense.
Thanks,
-Steve
--- iptables.c 2011-02-28 23:03:32.000000000 -0800 +++ iptables.c_new 2011-05-18 14:00:59.110855881 -0700 @@ -51,7 +51,8 @@
enum { ADD = 0, - REMOVE + REMOVE, + APPEND };
typedef struct @@ -111,7 +112,7 @@ ? IP6TABLES_PATH : IPTABLES_PATH);
virCommandAddArgList(cmd, "--table", rules->table, - action == ADD ? "--insert" : "--delete", + action == ADD ? "--insert" : action == REMOVE ? "--delete" : "--append", rules->chain, arg, NULL);
va_start(args, arg); @@ -666,7 +667,7 @@ int family, const char *iface) { - return iptablesForwardRejectOut(ctx, family, iface, ADD); + return iptablesForwardRejectOut(ctx, family, iface, APPEND); }
/** @@ -722,7 +723,7 @@ int family, const char *iface) { - return iptablesForwardRejectIn(ctx, family, iface, ADD); + return iptablesForwardRejectIn(ctx, family, iface, APPEND); }
'ADD' caused an 'insertion' at position 0. Now 'APPEND' appends the new rule to the end. To me it makes sense per-se to put the reject rules to
On 06/22/2011 06:01 PM, Eric Blake wrote: the end. There shoudn't be any negative side effects because of this. So I'd give it an ACK. Stefan
/**
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list