You have to introduce a new set type version whenever a new feature is
added: in your patches there is no protection against mixed cases, when
only the kernel or just the userspace is upgraded. Or one side is
downgraded for whatever reason.
You mean object version (similar to the one you had a debate about on
this ML with Mr Engelhardt a while ago)?
As for protection against mixed case uses - I don't think there is a
need for one. There are two possible scenarios worth considering:- using
old iptables + new kernel and using new iptables + old kernel.
With the first case, iptables simply won't accept 'in' or 'out' values
even if the kernel can process them. So, to me that is not an issue.
With the second case, again, even if iptables accept 'in' and 'out' as
values, because the patches I submitted yesterday allow for backwards
compatibility, the kernel would be able to process these matches without
any issues.
If you look at the code, the iptables code is raising both DIM_TWO_SRC
as well as the new DIM_IFACE bits in the 'flags' variable. The set
matching functions of the "old" kernel will "know" of and take into
account just the DIM_TWO_SRC bit to produce a match, which is quite fine
and it is how is supposed to work in the first place, so again, a match
will be produced and I don't see any issues here either.
If you think there would be any issues of mixed case uses, please
elaborate why do you think that is and give me an example (I am
excluding the list:set type as this is a bit of a special case - see below)?
You must handle the case of the list:set type: how should then the new
"in", "out" be interpreted?
As I already pointed out in the patches yesterday, 'in' and 'out' have
only one single purpose - to match against network interfaces. Nothing
else!
'In' - means incoming interface, 'out' means outgoing. It doesn't make
sense at all to be used anywhere else - if they are allowed to be used
to specify source/destination ip addresses/subnets, protocols or ports,
this would be completely nonsensical. It is also why I am dead against
the idea 'in' and 'out' to be considered as simply a "synonym" of 'src'
and 'dst' as you suggest below.
Again, 'in' and 'out' are only meant and should only be used for
interfaces, nothing else.
Or should those be rejected? But then it'd
mean that if someone used a hash:net,iface type as a member of list:set,
then he is forced to use "src", "dst" only.
It would help if I use an example for this.
If I create a list set (lets call it list1) consisting of, say, 2
hash:net,iface set members (lets call them iface1 and iface2) and 3
other hash:ip,port set members (lets call them ipp1, ipp2 and ipp3) and
if I then execute the following iptables statement:
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
The above statement will *only* match packets against members of the
list1 set which have a matching source IP address and incoming interface
- iface1 and iface2 in this case. ipp1, ipp2 and ipp3 won't be matched.
This makes perfect sense, given what I have written above (and in the
patches I submitted yesterday) about the definition of 'in' and 'out' -
it means match *only* against the incoming or outgoing interfaces.
However, if I execute the following iptables statement:
iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
That would match packets against *all* members of the list1 set (iface1,
iface2, ipp1, ipp2 and ipp3 this time) which have a matching source IP
address, incoming interface as well as src port values. Again, I see
nothing wrong with that and the fact that there is additional "filter"
for 'in' and 'out' values - well, I consider this an added feature, if
anything.
It'd be much simpler to introduce the keywords as aliases, all over:
"in" as "dst" and "out" as "src", and print them with hash:net,iface only.
Simpler for whom? It can't be for the end user, because referring to,
say, destination IP address as "out" IP address is even more ridiculous
than using 'src' and 'dst' designators for network interfaces. Quite
astonishing that!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
