[libvirt] Appending REJECT rules.
Stefan Berger
stefanb at linux.vnet.ibm.com
Thu Jun 23 00:58:29 UTC 2011
On 06/22/2011 06:01 PM, Eric Blake wrote:
> On 05/18/2011 03:10 PM, Stephen O'Dor wrote:
>> Greetings folks,
> Hello, and sorry for the delayed response. Looks like this fell through
> 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
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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
More information about the libvir-list
mailing list