Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Christian Brauner <christian.brauner@ubuntu.com>
Cc:     linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        contact@linuxplumbersconf.org
References: <CAHrFyr4AYi_gad7LQ-cJ9Peg=Gt73Sded8k_ZHeRZz=faGzpQA@mail.gmail.com>
Date:   Mon, 27 Sep 2021 16:51:05 -0500
In-Reply-To: <CAHrFyr4AYi_gad7LQ-cJ9Peg=Gt73Sded8k_ZHeRZz=faGzpQA@mail.gmail.com>
        (Christian Brauner's message of "Mon, 27 Sep 2021 23:21:00 +0200")
Message-ID: <87pmst4rhy.fsf@disp2133>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [lpc-contact] Linux Plumbers Conference Last Day
Precedence: bulk

Christian Brauner <christian.brauner@ubuntu.com> writes:

> I'm expanding the Cc on this since this has crossed a clear line now.

What asking people to fix their bugs?

Sitting out and not engaging because this situation is very frustrating
when people refuse to fix their bugs?

> You have claimed on two occasions on the PR itself (cf. [1]) and in a
> completely unrelated thread on fsdevel (cf. [2]) that there exist bugs in the
> current implementation.
> On both occasions (cf. [3], [4]) we have responded and asked you to please
> disclose those bugs and provide reproducers. You have not responded on both
> occasions.

You acknowledged the trivial bug in chown_common that affects security
modules and exists to this day.

It is trivial to see all you have to do is look at the stomp of uid and
gid.

The other bug I gave details of you and it the tracing was tricky and
you did not agree.  Last I looked it is also there.

> I ask you to stop spreading demonstrably false information such as that we are
> refusing to fix bugs. The links clearly disprove your claims.
> We are more than happy to fix any bugs that exist. But we can't if we don't
> know what they are.

Hog wash.

A demonstration is a simple as observing that security_path_chown very
much gets a different uid and gid values than it used to.

I have been able to dig in far enough to see that the idmapped mounts
code does not have issues when you are not using idmapped mounts, and I
am not using idmapped mounts.  So dealing with this has not been a
priority for me.

All I have seen you do on this issue is get frustrated.  I am very
frustrated also.

All I was intending to say was that if we could sit down in person at
LPC we could probably sort this all out quickly, and get past this our
frustrations with each other.  As it is, I don't know a quick way to
resolve our frustrations easily.

Eric