[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <66ror6q2-7pq2-os23-rq8r-8426ppr6pnps@vanv.qr>
Date: Mon, 7 Apr 2025 12:56:33 +0200 (CEST)
From: Jan Engelhardt <ej@...i.de>
To: Florian Westphal <fw@...len.de>
cc: lvxiafei <xiafei_xupt@....com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>, lvxiafei <lvxiafei@...setime.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org
Subject: Re: [PATCH] netfilter: netns nf_conntrack: per-netns
net.netfilter.nf_conntrack_max sysctl
On Monday 2025-04-07 12:13, Florian Westphal wrote:
>lvxiafei <xiafei_xupt@....com> wrote:
>> The modification of nf_conntrack_max in one netns
>> should not affect the value in another one.
>
>nf_conntrack_max can only be changed in init_net.
>
>Given the check isn't removed:
> /* Don't allow non-init_net ns to alter global sysctls */
> if (!net_eq(&init_net, net)) {
> table[NF_SYSCTL_CT_MAX].mode = 0444;
>
>... this patch seems untested?
>
>But, removing this check would allow any netns to consume
>arbitrary amount of kernel memory.
>
>How do you prevent this?
By inheriting an implicit limit from the parent namespace somehow.
For example, even if you set the kernel.pid_max sysctl in the initial
namespace to something like 9999, subordinate namespace have
kernel.pid_max=4million again, but nevertheless are unable to use
more than 9999 PIDs. Or so documentation the documentation
from commit d385c8bceb14665e935419334aa3d3fac2f10456 tells me
(I did not try to create so many processes by myself).
A similar logic would have to be applied for netfilter sysctls
if they are made modifiable in subordinate namespaces.
Powered by blists - more mailing lists