On Fri, Sep 24, 2021 at 11:29:12AM -0500, Eric W. Biederman wrote:
> James Bottomley <[email protected]> writes:
>
> > Dear Eric,
> >
> > Thank you again for coming to Linux Plumbers Conference, we're hoping
> > to make it one of the best technical conferences of the year, with
> > your help. The conference should start up in about 15 minutes at
> > 07:00PDT/14:00UTC. However, some Microconferences do start early, so
> > check out the timetable:
> >
> > https://linuxplumbersconf.org/event/11/timetable/#20210924
> >
> > And on that note: we'll be running an hour longer today (finishing at
> > 19:00 UTC) to accommodate the closing keynote which will include a
> > beer BoF, the traditional show your pets Gala and a discussion of the
> > results of the 30 years of linux survey. A reminder to those
> > procrastinators among you: please fill out the looking forwards to the
> > next thirty years survey here:
>
> I regret to write to tell you that I will not be attending the closing
> bof.
>
> I need to get into the same room and talk things out with Christian
> Brauner. Currently he has been refusing fixing security bugs in
> idmapped mounts for several releases, and I just haven't had the
> time/energy to deal with it. Thankfully not much is using idmapped
> mounts yet, and the issues don't affect the code unless you are have
> enabled idmapped mounts.
>
> Last year was a disaster in failed communications and agreements on what
> we should do. This year the microconference was very much toned down,
> and we did not manage to resolve anything.
>
> So my apologies but unfortunately for me the not-in-person setting
> really has really made LPC not worth attending this year.
>
I'm expanding the Cc on this since this has crossed a clear line now.
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.
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.
If it is true that there are bugs that you have known about for over a year
that you haven't disclosed then this is extremely irresponsible.
This outlandish approach towards technical conflict resolution that you have
chosen for the last year has turned any potential future bug in the
implementation of a complicated patchset into a hugely political thing.
I refuse to let that happen. If there are bugs we fix them just like we always
do. We don't use bugs as political pawns to score points or attack our peers.
We come together as a community to fix them and then we move on.
Last week during LPC you were in the same room with me and others for 4 hours
straight on Monday. You were also present in the talk I gave on this in the
filesystem MC with opportunity for discussion after the talk.
Your contribution to this discussion was a single line in the chat:
"Please fix the implementation bugs before you relax the permissions."
You could have handed in a session to any of those two MCs, you could've asked
for a hackroom meeting, you could've approached us in the chat. None of that
happened. What happened was yet another very unpleasant passive-aggressive
attack.
I've been asking a lot of people for advice on how to deal with this since this
isn't the first time you resort to this strategy. The new mount API is another
example where you kept claiming serious bugs exist but never provided proof.
I was fine with ascribing a good chunk of this behavior to a lack in some basic
developer and maintainer etiquette but this mail has crossed a line for me.
Other developers literally come up to me and ask me what's going on there. To
which I have no real answer.
But this recent mail has a crossed a line for me because you're now even coming
after me by going through third parties spreading demonstrably false
information at a public event that I'm helping organize. This needs to stop!
Frankly, all of this has eroded any trust I have in you as a maintainer. None
of this has bee good faith for a while now.
Please, provide the details and reproducers on the bugs so we can discuss them
or send patches with tests. I will happily pick them up and send them to Linus.
Christian
[1]: https://lore.kernel.org/lkml/[email protected]/T/#m3a9df31aa183e8797c70bc193040adfd601399ad
[2]: https://lore.kernel.org/lkml/[email protected]
[3]: https://lore.kernel.org/lkml/[email protected]/T/#m59cdad9630d5a279aeecd0c1f117115144bc15eb
[4]: https://lore.kernel.org/lkml/20210510125147.tkgeurcindldiwxg@wittgenstein
Christian Brauner <[email protected]> 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
On Mon, Sep 27, 2021 at 04:51:05PM -0500, Eric W. Biederman wrote:
> Christian Brauner <[email protected]> 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?
I clearly explained why this has crossed a line in the prior mail. Cutting that
part off won't make it go away.
>
> > 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.
Stop the handwaving and stop claiming things that aren't true. The links in the
prior mail clearly disprove any of your claims. I did not acknowledge any bug.
And I did not do so because you have not provided any proof that this leads to
any issues. You claim that there are bugs. So the burden of proof is on you to
spell them out clearly and provide reproducers where this actually leads to
issues.
>
> 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.
If that really was your intention then again, you could have easily handed in a
session to either one of the microconferences that I ran and presented in, you
could've easily asked for a hackroom session. You could've written a normal
mail addressing the issue. None of that happened. Your actions clearly speak
against any intention of resolving this constructively so far.
It is not our task to to chase after you in order to get you to tell us
what your problem is. You need to find better, less passive-aggressive
ways to deal with your frustrations.
Here is my proposal to resolve this. The Linux Plumbers infrastructure is well
alive and running and always there for on-demand meetings. I offer you a
virtual meeting with camera and audio to clear the air both socially and
technically. We will ask someone to be around as arbiter and to take notes
during that meeting so we have a track-record.
Christian