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
Subject: Re: [lpc-contact] Linux Plumbers Conference Last Day
Date: Mon, 27 Sep 2021 16:51:05 -0500 [thread overview]
Message-ID: <87pmst4rhy.fsf@disp2133> (raw)
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")
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
next prev parent reply other threads:[~2021-09-27 21:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 21:21 [lpc-contact] Linux Plumbers Conference Last Day Christian Brauner
2021-09-27 21:51 ` Eric W. Biederman [this message]
2021-09-28 18:12 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pmst4rhy.fsf@disp2133 \
--to=ebiederm@xmission.com \
--cc=christian.brauner@ubuntu.com \
--cc=contact@linuxplumbersconf.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox