On Sun, 15 Jul 2012, Mr Dash Four wrote:
> > > 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.
hash:net,iface is the only type where "in/out" is natural and makes sense.
There are nine other types, not counting list:set, where "in/out" simply
doesn't fit in.
And we are at list:set level, where all the members are hidden:
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
You are actually telling me: "it's the user decision, he/she knows how to
interpret "in" for all other types." But why should *one* type be favoured
in syntax against *nine* by list:set?
And what would be the output when the rule above is listed/saved? This
one?:
-A INPUT -m set --match-set list1 src,src -j ACCEPT
Then we are enforcing the syntax and someone has to scratch the head.
Moreover, if "in/out" is allowed with list:set types, which means that
actually all set types "support" them when they are members of list:set,
why isn't it supported openly for every type? Because that way it'd be
quite visible that "in/out" doesn't fit into the other types?
No. Send your patches according to solution a, that is the "in/out"
keywords are allowed only with hash:net,iface type of sets alone and
rejected with a proper error message when attempted to use with any other
set type.
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
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
