All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Rob Herring <robh@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH] MAINTAINERS: add namespace entry
Date: Tue, 25 Aug 2020 18:40:45 +0200	[thread overview]
Message-ID: <20200825164045.fkwws77einqbbhat@wittgenstein> (raw)
In-Reply-To: <87zh6in140.fsf@x220.int.ebiederm.org>

On Tue, Aug 25, 2020 at 11:26:07AM -0500, Eric W. Biederman wrote:
> 
> A) If we are going to have this discussion in public we really should
>    include the containers list.

Ah, just used the output from get_maintainers.pl.

> 
> B) The challenge is that most of the namespace work has become part of
>    it's upstream subsystem so we really need to list the containers
>    list and ourselves as reviewers, more than maintainers who run
>    a tree for the code.
> 
> C) You have overstated what I have agreed to here.
>    I have have previously said that I agree that having a MAINTAINERS
>    entry so people who are unfamiliar with the situation with namespaces
>    can find us.  Given that most of the changes going forward are likely
>    to be maintenance changes.
> 
>    I also said we need to talk about how we plan to maintain the code
>    here.
> 
>    It feels like you are pushing this hard, and I am not certain why you
>    are pushing and rushing this.  With my maintainer hat on my big
>    concern is we catch the issues that will introduce security issue.
>    Recently I have seen a report that there is an issue on Ubuntu
>    kernels where anyone can read /etc/shadow.  The problem is that
>    Ubuntu has not been cautions and has not taken the time to figure out
>    how to enable things for unprivileged users safely, and have just
>    enabled the code to be used by unprivileged users because it is
>    useful.
> 
>    In combination with you pushing hard and not taking the time to
>    complete this conversation in private with me, this MAINTAINERS entry
>    makes me uneasy as it feels like you may be looking for a way to push
>    the code into the mainline kernel like has been pushed into the
>    Ubuntu kernel.  I may be completely wrong I just don't know what to
>    make of your not finishing our conversation in private, and forcing
>    my hand by posting this patch publicly.
> 
> The files you have listed are reasonable for a maintainers entry as they
> have no other maintainers.
> 
> I know I have been less active after the birth of my young son, and I
> know the practical rule is that the person who does the work is the
> maintainer.  At the same time I am not convinced you are actually going
> to do the work to make new code maintainable and not a problem for other
> kernel developers.
> 
> A big part the job over the years has been to make the namespace ideas
> proposed sane, and to keep the burden from other maintainers of naive
> and terrible code.  Pushing this change before we finished our private
> conversation makes me very nervous on that front.

Ok, Eric. I've tried to do this with the best intentions possible and I
would assume that this is the default assumption everyone would have
after all these years. This type of response is very shocking to me and
I honestly don't know how to respond!

I'm dropping this completely because I'm not going to be accused of
having a hidden agenda! Such an accusation is imho completely out of
line and it is completely unacceptable to treat a peer like this!

Christian

  reply	other threads:[~2020-08-25 16:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 15:41 [PATCH] MAINTAINERS: add namespace entry Christian Brauner
2020-08-25 16:01 ` Joe Perches
2020-08-25 16:06   ` Christian Brauner
2020-08-25 16:26 ` Eric W. Biederman
2020-08-25 16:40   ` Christian Brauner [this message]
2020-08-25 18:27   ` Kees Cook
2020-08-26  7:26   ` Aleksa Sarai

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=20200825164045.fkwws77einqbbhat@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=robh@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.