I would like to see why do you think the use of in/out should be restricted in
list:set types, given the fact that there could be hash:net,iface members
registered in that type of set?
Why should I (and I am sure I am not going to be the only one) have to
scratch my head and think what is corresponding to 'src' and 'dst' every
time I place a hash:net,iface set member in a list:set and why I can't
make use of in or out, in addition to src/dst in that list:set?
Because this or that way, someone would scratch his/her head. For example
if the rule contains "in/out" and the list:set is a mixed one, contains
both hash:net,iface and other types of sets. They'll ask: "What the heck
is "in/out" for say hash:ip type of set?"
You still didn't answer my question: Why do you impose the restriction
in "solution a", given that the result from both solutions (a & b) are
exactly the same, which is what you wanted all along and which was the
main reason for you not wanting in/out to be allowed/entered in a
list:set in a first place?
What I have suggested to you was that you allow in/out to be *entered*,
as input, in a list:set (i.e. in the iptables statement), but treated
internally in the same way as src/dst ('in' to be treated internally as
'src', 'out' as 'dst' obviously). In that way, there won't be any
discrepancies and the results from both "solutions" will be the same. In
other words (using the example you gave earlier), typing:
-bash-~# iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
and
-bash-~# iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
to be both accepted and 'in', as *entered* above, to be interpreted in
the same way as 'src'. That way there won't be any "different" results.
This is, to my understanding, what "solution b" is. What you are asking
is 'in' to be rejected completely (i.e. not accepted as input) and only
the following to be allowed:
-bash-~# iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
even though in that list1 set I could have hash:net,iface elements. What
you are doing by this (and in "solution a") is placing an unnecessary
restriction on in/out and prevent it from being entered/accepted at all,
and that is why I asked you to justify that restriction.
The users are not morons (well, not all of them anyway) - they make a
concious decisions on what to use/enter as direction parameters, so I
think they should be allowed to enter in/out, particularly because the
list:set could contain hash:net,iface elements and it is why I think
in/out should be allowed.
--
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
