netfilter: Kconfig: IP6_NF_IPTABLES_LEGACY old =y behaviour question

netfilter: Kconfig: IP6_NF_IPTABLES_LEGACY old =y behaviour question

[Breno Leitao]

Hello Florian,

I am rebasing my workflow in into a new kernel, and I have a question
that you might be able to help me. It is related to
IP6_NF_IPTABLES_LEGACY Kconfig, and the change in a9525c7f6219cee9
("netfilter: xtables: allow xtables-nft only builds").

In my kernel before this change, I used to have ip6_tables "module" as
builtin (CONFIG_IP6_NF_IPTABLES=y), and all the other dependencies as
modules, such as IP6_NF_FILTER=m, IP6_NF_MANGLE=m, IP6_NF_RAW=m.

After the mentioned commit above, I am not able to have ip6_tables set
as a builtin (=y) anymore, give that it is a "hidden" configuration, and
the only way is to change some of the selectable dependencies
(IP6_NF_RAW for insntance) to be a built-in (=y).

That said, do you know if I can keep the ip6_tables as builtin without
changing any of the selectable dependencies configuration. In other
words, is it possible to keep the old behaviour (ip6_table builtin and
the dependenceis as modules) with the new IP6_NF_IPTABLES_LEGACY
configuration?

Thank you!
--breno

Re: netfilter: Kconfig: IP6_NF_IPTABLES_LEGACY old =y behaviour question

[Florian Westphal]

Breno Leitao <leitao@debian.org> wrote:
> Hello Florian,
> 
> I am rebasing my workflow in into a new kernel, and I have a question
> that you might be able to help me. It is related to
> IP6_NF_IPTABLES_LEGACY Kconfig, and the change in a9525c7f6219cee9
> ("netfilter: xtables: allow xtables-nft only builds").
> 
> In my kernel before this change, I used to have ip6_tables "module" as
> builtin (CONFIG_IP6_NF_IPTABLES=y), and all the other dependencies as
> modules, such as IP6_NF_FILTER=m, IP6_NF_MANGLE=m, IP6_NF_RAW=m.
> 
> After the mentioned commit above, I am not able to have ip6_tables set
> as a builtin (=y) anymore, give that it is a "hidden" configuration, and
> the only way is to change some of the selectable dependencies
> (IP6_NF_RAW for insntance) to be a built-in (=y).
> 
> That said, do you know if I can keep the ip6_tables as builtin without
> changing any of the selectable dependencies configuration. In other
> words, is it possible to keep the old behaviour (ip6_table builtin and
> the dependenceis as modules) with the new IP6_NF_IPTABLES_LEGACY
> configuration?

No.  But why would you need it?
ip6_tables.c is only relevant for the various tables.

You could make a patch for nf-next that exposes those symbols as per description
in a9525c7f6219cee9284c0031c5930e8d41384677, i.e. with 'depends on'
change.

Re: netfilter: Kconfig: IP6_NF_IPTABLES_LEGACY old =y behaviour question

[Breno Leitao]

Hello Florian,

On Thu, Aug 22, 2024 at 01:23:39PM +0200, Florian Westphal wrote:
> Breno Leitao <leitao@debian.org> wrote:
> > Hello Florian,
> > 
> > I am rebasing my workflow in into a new kernel, and I have a question
> > that you might be able to help me. It is related to
> > IP6_NF_IPTABLES_LEGACY Kconfig, and the change in a9525c7f6219cee9
> > ("netfilter: xtables: allow xtables-nft only builds").
> > 
> > In my kernel before this change, I used to have ip6_tables "module" as
> > builtin (CONFIG_IP6_NF_IPTABLES=y), and all the other dependencies as
> > modules, such as IP6_NF_FILTER=m, IP6_NF_MANGLE=m, IP6_NF_RAW=m.
> > 
> > After the mentioned commit above, I am not able to have ip6_tables set
> > as a builtin (=y) anymore, give that it is a "hidden" configuration, and
> > the only way is to change some of the selectable dependencies
> > (IP6_NF_RAW for insntance) to be a built-in (=y).
> > 
> > That said, do you know if I can keep the ip6_tables as builtin without
> > changing any of the selectable dependencies configuration. In other
> > words, is it possible to keep the old behaviour (ip6_table builtin and
> > the dependenceis as modules) with the new IP6_NF_IPTABLES_LEGACY
> > configuration?
> 
> No.  But why would you need it?

In certain environments, iptables needs to run, but there is *no*
permission to load modules.

For those cases, I have CONFIG_IP6_NF_IPTABLES configured as y in
previous kernels, and now it becomes a "m", which doesn't work because
iptables doesn't have permission to load modules, returning:

	$ ip6tables -L
	modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/....
	ip6tables v1.8.10 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
	Perhaps ip6tables or your kernel needs to be upgraded.

> You could make a patch for nf-next that exposes those symbols as per description
> in a9525c7f6219cee9284c0031c5930e8d41384677, i.e. with 'depends on'
> change.

Sure, I am happy to do it, but I would like to understand a bit better
before. Does it mean we make IP_NF_IPTABLES_LEGACY selectable by the
user, and changes the dependable configs from "selects" to "depends on"?
Something as the following (not heavily tested)?

Thanks for the quick answer!
--breno

Author: Breno Leitao <leitao@debian.org>
Date:   Thu Aug 22 05:35:41 2024 -0700
    netfilter: Make IP_NF_IPTABLES_LEGACY selectable
    
    This option makes IP_NF_IPTABLES_LEGACY user selectable, giving
    users the option to configure iptables without enabling any other
    config.
    
    Suggested-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Breno Leitao <leitao@debian.org>

diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index 1b991b889506..b5ff14a5272a 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -12,7 +12,11 @@ config NF_DEFRAG_IPV4
 
 # old sockopt interface and eval loop
 config IP_NF_IPTABLES_LEGACY
-	tristate
+	tristate "Legacy IP tables support"
+	default	n
+	select NETFILTER_XTABLES
+	help
+	  iptables is a general, extensible packet identification legacy framework.
 
 config NF_SOCKET_IPV4
 	tristate "IPv4 socket lookup support"
@@ -177,7 +181,7 @@ config IP_NF_MATCH_TTL
 config IP_NF_FILTER
 	tristate "Packet filtering"
 	default m if NETFILTER_ADVANCED=n
-	select IP_NF_IPTABLES_LEGACY
+	depends on IP_NF_IPTABLES_LEGACY
 	help
 	  Packet filtering defines a table `filter', which has a series of
 	  rules for simple packet filtering at local input, forwarding and
@@ -217,7 +221,7 @@ config IP_NF_NAT
 	default m if NETFILTER_ADVANCED=n
 	select NF_NAT
 	select NETFILTER_XT_NAT
-	select IP_NF_IPTABLES_LEGACY
+	depends on IP_NF_IPTABLES_LEGACY
 	help
 	  This enables the `nat' table in iptables. This allows masquerading,
 	  port forwarding and other forms of full Network Address Port
@@ -258,7 +262,7 @@ endif # IP_NF_NAT
 config IP_NF_MANGLE
 	tristate "Packet mangling"
 	default m if NETFILTER_ADVANCED=n
-	select IP_NF_IPTABLES_LEGACY
+	depends on IP_NF_IPTABLES_LEGACY
 	help
 	  This option adds a `mangle' table to iptables: see the man page for
 	  iptables(8).  This table is used for various packet alterations
@@ -293,7 +297,7 @@ config IP_NF_TARGET_TTL
 # raw + specific targets
 config IP_NF_RAW
 	tristate  'raw table support (required for NOTRACK/TRACE)'
-	select IP_NF_IPTABLES_LEGACY
+	depends on IP_NF_IPTABLES_LEGACY
 	help
 	  This option adds a `raw' table to iptables. This table is the very
 	  first in the netfilter framework and hooks in at the PREROUTING
@@ -305,9 +309,7 @@ config IP_NF_RAW
 # security table for MAC policy
 config IP_NF_SECURITY
 	tristate "Security table"
-	depends on SECURITY
-	depends on NETFILTER_ADVANCED
-	select IP_NF_IPTABLES_LEGACY
+	depends on SECURITY && NETFILTER_ADVANCED && IP_NF_IPTABLES_LEGACY
 	help
 	  This option adds a `security' table to iptables, for use
 	  with Mandatory Access Control (MAC) policy.

Re: netfilter: Kconfig: IP6_NF_IPTABLES_LEGACY old =y behaviour question

[Florian Westphal]

Breno Leitao <leitao@debian.org> wrote:
> On Thu, Aug 22, 2024 at 01:23:39PM +0200, Florian Westphal wrote:
> > Breno Leitao <leitao@debian.org> wrote:
> > > Hello Florian,
> > > 
> > > I am rebasing my workflow in into a new kernel, and I have a question
> > > that you might be able to help me. It is related to
> > > IP6_NF_IPTABLES_LEGACY Kconfig, and the change in a9525c7f6219cee9
> > > ("netfilter: xtables: allow xtables-nft only builds").
> > > 
> > > In my kernel before this change, I used to have ip6_tables "module" as
> > > builtin (CONFIG_IP6_NF_IPTABLES=y), and all the other dependencies as
> > > modules, such as IP6_NF_FILTER=m, IP6_NF_MANGLE=m, IP6_NF_RAW=m.
> > > 
> > > After the mentioned commit above, I am not able to have ip6_tables set
> > > as a builtin (=y) anymore, give that it is a "hidden" configuration, and
> > > the only way is to change some of the selectable dependencies
> > > (IP6_NF_RAW for insntance) to be a built-in (=y).
> > > 
> > > That said, do you know if I can keep the ip6_tables as builtin without
> > > changing any of the selectable dependencies configuration. In other
> > > words, is it possible to keep the old behaviour (ip6_table builtin and
> > > the dependenceis as modules) with the new IP6_NF_IPTABLES_LEGACY
> > > configuration?
> > 
> > No.  But why would you need it?
> 
> In certain environments, iptables needs to run, but there is *no*
> permission to load modules.
> 
> For those cases, I have CONFIG_IP6_NF_IPTABLES configured as y in
> previous kernels, and now it becomes a "m", which doesn't work because
> iptables doesn't have permission to load modules, returning:
> 
> 	$ ip6tables -L
> 	modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/....
> 	ip6tables v1.8.10 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
> 	Perhaps ip6tables or your kernel needs to be upgraded.

Hmm, but how can that work?  If you can't load modules, you can't load
ip6t_filter either.

And if thats builtin, then IP6_NF_IPTABLES_LEGACY is supposed to become
=y too.

> > You could make a patch for nf-next that exposes those symbols as per description
> > in a9525c7f6219cee9284c0031c5930e8d41384677, i.e. with 'depends on'
> > change.
> 
> Sure, I am happy to do it, but I would like to understand a bit better
> before. Does it mean we make IP_NF_IPTABLES_LEGACY selectable by the
> user, and changes the dependable configs from "selects" to "depends on"?
> Something as the following (not heavily tested)?
> 
> Thanks for the quick answer!
> --breno
> 
> Author: Breno Leitao <leitao@debian.org>
> Date:   Thu Aug 22 05:35:41 2024 -0700
>     netfilter: Make IP_NF_IPTABLES_LEGACY selectable
>     
>     This option makes IP_NF_IPTABLES_LEGACY user selectable, giving
>     users the option to configure iptables without enabling any other
>     config.
>     
>     Suggested-by: Florian Westphal <fw@strlen.de>
>     Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
> index 1b991b889506..b5ff14a5272a 100644
> --- a/net/ipv4/netfilter/Kconfig
> +++ b/net/ipv4/netfilter/Kconfig
> @@ -12,7 +12,11 @@ config NF_DEFRAG_IPV4
>  
>  # old sockopt interface and eval loop
>  config IP_NF_IPTABLES_LEGACY
> -	tristate
> +	tristate "Legacy IP tables support"
> +	default	n
> +	select NETFILTER_XTABLES
> +	help
> +	  iptables is a general, extensible packet identification legacy framework.

I would also add that this isn't needed for iptables-nft (iptables over
nftables api).

Otherwise, yes, something like that.

Re: netfilter: Kconfig: IP6_NF_IPTABLES_LEGACY old =y behaviour question

[Breno Leitao]

Hello Florian,

On Thu, Aug 22, 2024 at 03:20:22PM +0200, Florian Westphal wrote:
> Breno Leitao <leitao@debian.org> wrote:
> > On Thu, Aug 22, 2024 at 01:23:39PM +0200, Florian Westphal wrote:

> > In certain environments, iptables needs to run, but there is *no*
> > permission to load modules.
> > 
> > For those cases, I have CONFIG_IP6_NF_IPTABLES configured as y in
> > previous kernels, and now it becomes a "m", which doesn't work because
> > iptables doesn't have permission to load modules, returning:
> > 
> > 	$ ip6tables -L
> > 	modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/....
> > 	ip6tables v1.8.10 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
> > 	Perhaps ip6tables or your kernel needs to be upgraded.
> 
> Hmm, but how can that work?  If you can't load modules, you can't load
> ip6t_filter either.

This happens inside a container that has no support for module loading, and
expects the tables to be =y.

> And if thats builtin, then IP6_NF_IPTABLES_LEGACY is supposed to become
> =y too.

Correct, both of them (IP6_NF_IPTABLES_LEGACY and IP_NF_IPTABLES_LEGACY)
was able to be user selectable, and they are not anymore, causing this
behaviour change.

Thanks for your support,
--breno