linux-kernel - Re: [REVIEW][PATCH 00/11] ipc: Fixing the pid namespace support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <874lky911j.fsf@xmission.com>
Date:   Thu, 29 Mar 2018 13:42:00 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     Linux Containers <containers@...ts.linux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        khlebnikov@...dex-team.ru, prakash.sangappa@...cle.com,
        luto@...nel.org, akpm@...ux-foundation.org, oleg@...hat.com,
        serge.hallyn@...ntu.com, esyr@...hat.com, jannh@...gle.com,
        linux-security-module@...r.kernel.org,
        Pavel Emelyanov <xemul@...nvz.org>,
        Nagarathnam Muthusamy <nagarathnam.muthusamy@...cle.com>
Subject: Re: [REVIEW][PATCH 00/11] ipc: Fixing the pid namespace support

Davidlohr Bueso <dave@...olabs.net> writes:

> On Fri, 23 Mar 2018, Eric W. Biederman wrote:
>
>>Still I would like to see this fixed and I plan on merging this code.

The code is merged into my for-next tree now.

> Yes, it needs fixed, but 1) there are pending issues (such as the
> extra atomics)

Concerns not issues.  I documented them but I don't see any serious
reason to be concerned.  The data structures are sufficiently different
from AF_UNIX as well as the usage patterns that I have no reasonable
expectation that there will be problems.

There is no reasonable alternate implementation for correcting this bug.
Because of my concerns I looked at several other possibilities and they
all showed incorrect behavior, in different circumstances.

The implementations are simple enough there are no deep subtle issues.

I have tested the code.

If a regression happens the code is carefully split up so things can be
bisected easily and reverted if necessary.

> and 2) its late in the -rc cycle. Plus this issue has existed for 11 years without
> the world ending, so I'm sure we can hold on until at least one more
> release.

People really are starting to seriously look at accessing a single ipc
namespace from multiple pid namespaces.  The work arounds I saw posted
for the current brokenness were too nasty to live.

Better to fix things before there is code that actually starts depending
on the current brokenness.

I am the namespace maintianer and this is my area of responsibility.

The code is ready and I see no reason or benefit in delay.

Eric