netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Netfilter Core Team <netfilter-devel@vger.kernel.org>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH v2 3/3] ipset: change 'iface' part in hash:net,iface set
Date: Mon, 16 Jul 2012 13:39:06 +0100	[thread overview]
Message-ID: <50040B6A.608@googlemail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207160924370.5297@blackhole.kfki.hu>


> 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.
>   
I disagree. The use of in/out "makes sense" where the 'iface' part is 
used (by being used I mean where it produces matches, obviously). There 
are currently only 2 sets which are capable of that: hash:net,iface and 
list:set. That is where it "makes sense" to allow in/out. In all other 
sets, the chances of matching against 'iface' are nil and that is why it 
"makes sense" to not even consider introducing in/out there.

> 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?
>   
Allowing in/out alongside src/dst isn't in any way "favouring" one over 
the other. If anything, I'd argue that by restricting list:set to only 
accept src/dst you are favouring that over in/out despite the fact that 
hash:net,iface could be used there as well.

As for the other "nine" types - see above. In/out only "makes sense" to 
be used where 'iface' is used. The last time I checked, the possibility 
of matching 'iface' in, say, bitmap:ip type set is the grant total of 
one big fat zero.

> 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.
>   
The output (i.e. what the user sees after the actual rule is entered) is 
a different issue altogether from the input, which is what we are 
currently discussing.

If in/out is allowed, then the output can take many forms acceptable to 
the user and there are many different ways in which that output could be 
produced in such a way so that there are no ambiguities as to what will 
be matched against, particularly with the new enhancements to the print 
functions in the set match/target I introduced.

Provided in/out is accepted as input in list:set types, I am confident I 
could produce output which will be consistent with what was entered and 
what ipset will match against and there will be no ambiguities.

> 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, 
>   
How did you manage to conclude that exactly? Look at the first paragraph 
I have written above - hash:net,iface (and the 'iface' part in 
particular) can only be registered/seen/used/deployed in two type of 
sets: hash:net,iface and list:set.

Let me ask you this then - what do you think 'in' and 'out' is?

> why isn't it supported openly for every type?
Because the 'iface' part isn't supported in any other types, that's why.

> 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.
>   
You keep banging on about "send me the patches according to solution a", 
but you are unwilling or unable to address the consequences of this and 
the issues I raised in this regard. Once this is done and I am convinced 
that this is the way to go, I'll send you the new patches.

This isn't some sort of Stalin-like republic where you can just order me 
to "send you the patches" and I do as I am told, OK? This is a free 
forum where we, as peers, are allowed to discuss these issues. If you 
are unable to hold to your arguments after I shot them to pieces, do you 
think that by ordering me to "send you the patches" I am going to 
concede and do as I am told?

Or do you think that just because you've written parts of the ipset code 
you could just order me to "send you the patches" I'll bow my head and 
say "yes, sir, I'll do it sir, right away sir"? Really? Get a grip of 
yourself Jozsef!

  reply	other threads:[~2012-07-16 12:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 22:23 [PATCH v2 0/3] iptables: change 'iface' part in hash:net,iface set Mr Dash Four
2012-07-09 22:23 ` [PATCH v2 1/3] " Mr Dash Four
2012-07-10 15:54   ` Jozsef Kadlecsik
2012-07-10 23:41     ` Mr Dash Four
2012-07-12  7:11       ` Jozsef Kadlecsik
2012-07-13  0:41         ` Mr Dash Four
2012-07-13  8:11           ` Jozsef Kadlecsik
2012-07-13 13:56             ` Mr Dash Four
2012-07-09 22:23 ` [PATCH v2 2/3] ipset: " Mr Dash Four
2012-07-10 15:35   ` Jozsef Kadlecsik
2012-07-09 22:23 ` [PATCH v2 3/3] " Mr Dash Four
2012-07-10 15:32   ` Jozsef Kadlecsik
2012-07-10 23:41     ` Mr Dash Four
2012-07-11 20:25       ` Jozsef Kadlecsik
2012-07-13  0:42         ` Mr Dash Four
2012-07-13  8:02           ` Jozsef Kadlecsik
2012-07-13 13:57             ` Mr Dash Four
2012-07-13 14:16               ` Jozsef Kadlecsik
2012-07-13 14:22                 ` Mr Dash Four
2012-07-14  8:45                   ` Jozsef Kadlecsik
2012-07-14 12:35                     ` Mr Dash Four
2012-07-14 16:37                       ` Jozsef Kadlecsik
2012-07-15 11:54                         ` Mr Dash Four
2012-07-15 15:02                           ` Jozsef Kadlecsik
2012-07-15 16:32                             ` Mr Dash Four
2012-07-15 19:21                               ` Jozsef Kadlecsik
2012-07-15 19:39                                 ` Jozsef Kadlecsik
2012-07-15 22:14                                 ` Mr Dash Four
2012-07-16  8:03                                   ` Jozsef Kadlecsik
2012-07-16 12:39                                     ` Mr Dash Four [this message]
2012-07-16 13:58                                       ` Jozsef Kadlecsik
2012-07-17 23:29                                         ` Mr Dash Four
2012-07-18 12:54                                           ` Jozsef Kadlecsik
2012-07-19 22:52                                             ` Mr Dash Four
2012-07-19 22:52                                           ` Mr Dash Four
2012-07-15 22:48                                 ` Mr Dash Four

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50040B6A.608@googlemail.com \
    --to=mr.dash.four@googlemail.com \
    --cc=kaber@trash.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).