linux-kernel - Re: 2.6.20-rc4: regression: iptables failed to load rules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0701100803270.3594@woody.osdl.org>
Date:	Wed, 10 Jan 2007 08:15:55 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Patrick McHardy <kaber@...sh.net>
cc:	Tomasz Kvarsin <kvarsin@...il.com>,
	"David S. Miller" <davem@...emloft.net>, bunk@...sta.de,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	netfilter@...ts.netfilter.org, netfilter-devel@...ts.netfilter.org
Subject: Re: 2.6.20-rc4: regression: iptables failed to load rules

On Wed, 10 Jan 2007, Patrick McHardy wrote:
> 
> In the x_tables case it really caused a lot of unnecessary confusion,
> the recent connection tracking changes however needed new config
> options since we're keeping the old implementation around for a few more
> releases.

It's too late now, but it _could_ have fairly easily been handled totally 
differently: namely by having the user-visible config options be 
INDEPENDENT of the actual back-end.

The Kconfig language is actually pretty powerful for configuration issues, 
and the way to do this is relatively straightforward:

	config CONNTRACK
		tristate "Netfilter support"
		...

	config NEW_CONTRACK_SUPPORT
		bool "Layer 3 Independent Connection tracking"
		...

	config CONNTRACK_MARK
		bool  'Connection mark tracking support'
		depends on CONNTRACK
		...

	config OLD_CONNTRACK_MARK
		bool
		depends on CONNTRACK_MARK && CONNTRACK && !NEW_CONTRACK_SUPPORT
		default y

	config NEW_CONNTRACK_MARK
		bool
		depends on CONNTRACK_MARK && CONNTRACK && NEW_CONTRACK_SUPPORT
		default y

See? The _user_ just sees a single "CONNTRACK_MARK" option (that just 
depends on the *generic* CONNTRACK config option), but then the Kconfig 
file splits that into "OLD_CONNTRACK_MARK" or "NEW_CONNTRACK_MARK" 
depending on whether "NEW_CONTRACK_SUPPORT" was set or not.

> It probably won't be necessary anymore to make changes like this in
> the future, but in case it is I'll make sure to at least provide
> compatibility options for a few releases.

In general, I'd much rather see the config options impact what the "user 
experience" should be. Notice how the above does exactly that: all the 
USER really cares about whether the connection marks are enabled or not, 
and the "NEW_CONTRACK_SUPPORT" is _not_ part of the user-visible config 
(apart from the _one_ question that asks about which implementation you 
want to pick), but it is only used to pick which _implementation_ to 
choose.

So making the Kconfig files more user-oriented and less implementation- 
oriented automatically solves the problem with config options that change 
names (because if the effect is the same, it should have the same name - 
regardless of how it is implemented!).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/