Re: ipset -R

[Mr Dash Four <mr.dash.four@googlemail.com>]

>>> However with hash:net type
>>>
>>> # ipset -N test hash:net
>>> # ipset -A test 10.1.1.0/24
>>> # ipset -D test 10.1.1.12
>>> ipset v6.0: Element cannot be deleted from the set: it's not added
>>>   
>>>       
>> Well, that's plain wrong, isn't it? The 'element' 10.1.1.12 does exist and it
>> is added (albeit implicitly as part of 10.1.1.0/24). I also presume 'ipset -T
>> test 10.1.1.12' will return a positive result, so there is something which
>> isn't quite right.
>>     
>
> 10.1.1.12/32 is not an explicit member of the set above, therefore you 
> cannot delete it.
>   
Right, so the error message should probably say "Element cannot be 
deleted from the set: it's not *explicitly* added" as this makes it more 
clear as the element in question is clearly added, though implicitly, 
via the 10.1.1.0/24 route.

I know this might be interpreted as 'just semantics', but it would avoid 
any type of confusion and would have spared me the typing trying to ask 
for clarify as to what the above error message means.

> At testing elements, the host addresses are a special case and checked 
> from the kernel point of view. So *testing* 10.1.1.12 returns a true 
> value. The reason for the exception is that the kernel at matching, 
> deleting, adding entries works on host addresses and that way one can 
> check the kernel view of the set from userspace.
>   
I take it that was done differently in the same kernel modules for ipset 
4.x, right?

>>> The hash:*net* types could be extended to store non-matching elements,
>>> something like this:
>>>
>>> # ipset -N test hash:net
>>> # ipset -A test 10.1.1.0/24
>>> # ipset -A test 10.1.1.12 --nomatch
>>>
>>> That way overlapping entries with different "access right" could be stored
>>> in a single set. But any coding needs time and testing.
>>>   
>>>       
>> I am not sure I understand the above - is this already implemented (in 6.0?)
>> or is this on the 'drawing board' so to speak? What do you mean by 'access
>> right'?
>>     
>
> Not implemented, just thinking. If the feature were implemented then the 
> testing in the set would return false for 10.1.1.12 and true for every 
> other element from 10.1.1.0/24.
>   
Call be dumb, but I still fail to see what is the sense in implementing 
the above, or are you suggesting that the above would create a pinhole 
with the "--nomatch" option instead of deleting the element itself and 
therefore remove the need for a 'whitelist'?

> With first case you spare the iptables rules and the matchings in 
> "whitelist".
>   
And, presumably, improve performance, right?

>  
>   
>> If so, how is the blacklist-all set stored - do you copy all the elements of
>> all the sets into a separate memory space or do you just reference the set
>> (which means that if I alter, say, blacklist-2, the changes are
>> 'automatically' applied to blacklist-all as well)?
>>     
>
> No copying whatsoever: the member sets are referenced and pointed to. 
> Please note, you cannot delete the member sets, however you can swap them 
> anytime with another, same type of set.
>   
Please clarify - can I remove elements of a set, i.e. execute "ipset -D 
blacklist-2 <blacklist-2 member(s)>", if blacklist-2 is part (i.e. a 
member) of a list set called blacklist-all, or do you mean that I cannot 
remove blacklist-2 from blacklist-all once added?

>> I can't combine all elements of my blacklist-x sets into one big one because
>> 1) I use separate blacklist-x sets elsewhere in my ip chains; and 2) my
>> blacklist-x sets are not of the same type.
>>     
You didn't clarify this point - can I have different type sub-sets as 
part of a list set or do they have to be of the same type?