netdev - Re: [PATCH RFC iptables] iptables: Per-net ns lock

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] [day] [month] [year] [list]

Message-ID: <b7432f5c-79bc-d790-124c-a06c57ac8b1a@virtuozzo.com>
Date:   Fri, 20 Apr 2018 14:24:01 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     Florian Westphal <fw@...len.de>
Cc:     netdev@...r.kernel.org, pablo@...filter.org, rstoyanov1@...il.com,
        ptikhomirov@...tuozzo.com, avagin@...tuozzo.com
Subject: Re: [PATCH RFC iptables] iptables: Per-net ns lock

Hi, Florian,

On 20.04.2018 13:50, Florian Westphal wrote:
> Kirill Tkhai <ktkhai@...tuozzo.com> wrote:
>> Pablo, Florian, could you please provide comments on this?
>>
>> On 09.04.2018 19:55, Kirill Tkhai wrote:
>>> In CRIU and LXC-restore we met the situation,
>>> when iptables in container can't be restored
>>> because of permission denied:
>>>
>>> https://github.com/checkpoint-restore/criu/issues/469
>>>
>>> Containers want to restore their own net ns,
>>> while they may have no their own mnt ns.
>>> This case they share host's /run/xtables.lock
>>> file, but they may not have permission to open
>>> it.
>>>
>>> Patch makes /run/xtables.lock to be per-namespace,
>>> i.e., to refer to the caller task's net ns.
> 
> It looks ok to me but then again the entire userspace
> lock thing is a ugly band aid :-/

I'm agree, but I'm not sure there is a possibility
to go away from it in classic iptables...

Kirill