[PATCH] MAINTAINERS: add namespace entry

[PATCH] MAINTAINERS: add namespace entry

[Christian Brauner]

Namespace maintainership has never been formalized which has led to confusion
when people need to determine where to send patches and who should take a look
at them. Especially, since we have a dedicated list
containers.lists.linuxfoundation.org already for a long time. In preparation of
this patch I added the containers.lists.linuxfoundation.org mailing list to be
archived on lore.

This will not just make it easier to catch and review patches specific to
namespaces and containers but also for changes not specifically touching
namespaces but which nevertheless will have impact on namespaces and
containers.

Add an entry for Eric (who agreed to this) and me and add a first batch of
files that are relevant. Currently, only a small set of files are added and
only such namespaces that haven't gotten a separate maintainers entry (e.g.
time namespaces). I expect this to grow more entries and/or regular expressions
over time. For now these entries here are sufficient. I intend to route this
patch upstream soon.

Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
 MAINTAINERS | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f0068bceeb61..272211cdc327 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11892,6 +11892,26 @@ S:	Supported
 W:	https://www.cspi.com/ethernet-products/support/downloads/
 F:	drivers/net/ethernet/myricom/myri10ge/
 
+NAMESPACES AND CONTAINERS
+M:     Christian Brauner <christian.brauner@ubuntu.com>
+M:     Eric W. Biederman <ebiederm@xmission.com>
+L:     containers.lists.linuxfoundation.org
+S:     Supported
+T:     https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/
+T:     https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/
+F:     ipc/namespace.c
+F:     kernel/nsproxy.c
+F:     kernel/pid_namespace.c
+F:     kernel/user_namespace.c
+F:     kernel/utsname.c
+F:     include/linux/nsproxy.h
+F:     include/linux/ipc_namespace.h
+F:     include/linux/ns_common.h
+F:     include/linux/nsproxy.h
+F:     include/linux/pid_namespace.h
+F:     include/linux/user_namespace.h
+F:     include/linux/utsname.h
+
 NAND FLASH SUBSYSTEM
 M:	Miquel Raynal <miquel.raynal@bootlin.com>
 R:	Richard Weinberger <richard@nod.at>

base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
-- 
2.28.0

Re: [PATCH] MAINTAINERS: add namespace entry

[Joe Perches]

On Tue, 2020-08-25 at 17:41 +0200, Christian Brauner wrote:
> Namespace maintainership has never been formalized which has led to confusion
> when people need to determine where to send patches and who should take a look
> at them. Especially, since we have a dedicated list
> containers.lists.linuxfoundation.org already for a long time. In preparation of
> this patch I added the containers.lists.linuxfoundation.org mailing list to be
> archived on lore.
> 
> This will not just make it easier to catch and review patches specific to
> namespaces and containers but also for changes not specifically touching
> namespaces but which nevertheless will have impact on namespaces and
> containers.
> 
> Add an entry for Eric (who agreed to this) and me and add a first batch of
> files that are relevant. Currently, only a small set of files are added and
> only such namespaces that haven't gotten a separate maintainers entry (e.g.
> time namespaces). I expect this to grow more entries and/or regular expressions
> over time. For now these entries here are sufficient. I intend to route this
> patch upstream soon.
> 
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
>  MAINTAINERS | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0068bceeb61..272211cdc327 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11892,6 +11892,26 @@ S:	Supported
>  W:	https://www.cspi.com/ethernet-products/support/downloads/
>  F:	drivers/net/ethernet/myricom/myri10ge/
>  
> +NAMESPACES AND CONTAINERS
> +M:     Christian Brauner <christian.brauner@ubuntu.com>
> +M:     Eric W. Biederman <ebiederm@xmission.com>
> +L:     containers.lists.linuxfoundation.org
> +S:     Supported
> +T:     https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/
> +T:     https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/
> +F:     ipc/namespace.c
> +F:     kernel/nsproxy.c
> +F:     kernel/pid_namespace.c
> +F:     kernel/user_namespace.c
> +F:     kernel/utsname.c
> +F:     include/linux/nsproxy.h
> +F:     include/linux/ipc_namespace.h
> +F:     include/linux/ns_common.h
> +F:     include/linux/nsproxy.h
> +F:     include/linux/pid_namespace.h
> +F:     include/linux/user_namespace.h
> +F:     include/linux/utsname.h

Please sort the filename order alphabetically.

F:	include/linux/ipc_namespace.h
F:	include/linux/ns_common.h
F:	include/linux/nsproxy.h
F:	include/linux/nsproxy.h
F:	include/linux/pid_namespace.h
F:	include/linux/user_namespace.h
F:	include/linux/utsname.h
F:	ipc/namespace.c
F:	kernel/nsproxy.c
F:	kernel/pid_namespace.c
F:	kernel/user_namespace.c
F:	kernel/utsname.c

Re: [PATCH] MAINTAINERS: add namespace entry

[Christian Brauner]

On Tue, Aug 25, 2020 at 09:01:01AM -0700, Joe Perches wrote:
> On Tue, 2020-08-25 at 17:41 +0200, Christian Brauner wrote:
> > Namespace maintainership has never been formalized which has led to confusion
> > when people need to determine where to send patches and who should take a look
> > at them. Especially, since we have a dedicated list
> > containers.lists.linuxfoundation.org already for a long time. In preparation of
> > this patch I added the containers.lists.linuxfoundation.org mailing list to be
> > archived on lore.
> > 
> > This will not just make it easier to catch and review patches specific to
> > namespaces and containers but also for changes not specifically touching
> > namespaces but which nevertheless will have impact on namespaces and
> > containers.
> > 
> > Add an entry for Eric (who agreed to this) and me and add a first batch of
> > files that are relevant. Currently, only a small set of files are added and
> > only such namespaces that haven't gotten a separate maintainers entry (e.g.
> > time namespaces). I expect this to grow more entries and/or regular expressions
> > over time. For now these entries here are sufficient. I intend to route this
> > patch upstream soon.
> > 
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> > ---
> >  MAINTAINERS | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index f0068bceeb61..272211cdc327 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11892,6 +11892,26 @@ S:	Supported
> >  W:	https://www.cspi.com/ethernet-products/support/downloads/
> >  F:	drivers/net/ethernet/myricom/myri10ge/
> >  
> > +NAMESPACES AND CONTAINERS
> > +M:     Christian Brauner <christian.brauner@ubuntu.com>
> > +M:     Eric W. Biederman <ebiederm@xmission.com>
> > +L:     containers.lists.linuxfoundation.org
> > +S:     Supported
> > +T:     https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/
> > +T:     https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/
> > +F:     ipc/namespace.c
> > +F:     kernel/nsproxy.c
> > +F:     kernel/pid_namespace.c
> > +F:     kernel/user_namespace.c
> > +F:     kernel/utsname.c
> > +F:     include/linux/nsproxy.h
> > +F:     include/linux/ipc_namespace.h
> > +F:     include/linux/ns_common.h
> > +F:     include/linux/nsproxy.h
> > +F:     include/linux/pid_namespace.h
> > +F:     include/linux/user_namespace.h
> > +F:     include/linux/utsname.h
> 
> Please sort the filename order alphabetically.
> 
> F:	include/linux/ipc_namespace.h
> F:	include/linux/ns_common.h
> F:	include/linux/nsproxy.h
> F:	include/linux/nsproxy.h
> F:	include/linux/pid_namespace.h
> F:	include/linux/user_namespace.h
> F:	include/linux/utsname.h
> F:	ipc/namespace.c
> F:	kernel/nsproxy.c
> F:	kernel/pid_namespace.c
> F:	kernel/user_namespace.c
> F:	kernel/utsname.c

Thanks, fixing now.
Christian

Re: [PATCH] MAINTAINERS: add namespace entry

[Eric W. Biederman]

A) If we are going to have this discussion in public we really should
   include the containers list.

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.

Eric

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

> Namespace maintainership has never been formalized which has led to confusion
> when people need to determine where to send patches and who should take a look
> at them. Especially, since we have a dedicated list
> containers.lists.linuxfoundation.org already for a long time. In preparation of
> this patch I added the containers.lists.linuxfoundation.org mailing list to be
> archived on lore.
>
> This will not just make it easier to catch and review patches specific to
> namespaces and containers but also for changes not specifically touching
> namespaces but which nevertheless will have impact on namespaces and
> containers.
>
> Add an entry for Eric (who agreed to this) and me and add a first batch of
> files that are relevant. Currently, only a small set of files are added and
> only such namespaces that haven't gotten a separate maintainers entry (e.g.
> time namespaces). I expect this to grow more entries and/or regular expressions
> over time. For now these entries here are sufficient. I intend to route this
> patch upstream soon.
>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
>  MAINTAINERS | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0068bceeb61..272211cdc327 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11892,6 +11892,26 @@ S:	Supported
>  W:	https://www.cspi.com/ethernet-products/support/downloads/
>  F:	drivers/net/ethernet/myricom/myri10ge/
>  
> +NAMESPACES AND CONTAINERS
> +M:     Christian Brauner <christian.brauner@ubuntu.com>
> +M:     Eric W. Biederman <ebiederm@xmission.com>
> +L:     containers.lists.linuxfoundation.org
> +S:     Supported
> +T:     https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/
> +T:     https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/
> +F:     ipc/namespace.c
> +F:     kernel/nsproxy.c
> +F:     kernel/pid_namespace.c
> +F:     kernel/user_namespace.c
> +F:     kernel/utsname.c
> +F:     include/linux/nsproxy.h
> +F:     include/linux/ipc_namespace.h
> +F:     include/linux/ns_common.h
> +F:     include/linux/nsproxy.h
> +F:     include/linux/pid_namespace.h
> +F:     include/linux/user_namespace.h
> +F:     include/linux/utsname.h
> +
>  NAND FLASH SUBSYSTEM
>  M:	Miquel Raynal <miquel.raynal@bootlin.com>
>  R:	Richard Weinberger <richard@nod.at>
>
> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd

Re: [PATCH] MAINTAINERS: add namespace entry

[Christian Brauner]

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

Re: [PATCH] MAINTAINERS: add namespace entry

[Kees Cook]

On Tue, Aug 25, 2020 at 11:26:07AM -0500, Eric W. Biederman wrote:
> 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.

As a person who has to touch multiple subsystems regularly while doing
treewide changes, I'm WAY happier to have a distinct set of maintainers
for specific files, and I can track the patch acceptance because I see
them appearing in a specific tree (via -next, etc).

> 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.

Eh? I don't see a conspiracy here; I think you are, as you suggest above,
completely wrong. ;) I haven't seen the private emails, obviously, but
what I see here is just Christian's drive to get things nailed down. It
sounds like the "here's who to CC" part of the MAINTAINERS file was
agreed to, but there was a misunderstanding about the resolution of
group maintainership?

> The files you have listed are reasonable for a maintainers entry as they
> have no other maintainers.

Agreed; if this was in place a few years ago, it might have been a bit
easier to direct and land some of the (now straggling) refcount_t
conversion patches.

> 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.

O_O  I find this opinion very surprising. I hold Christian's judgement
in high regard (and yours). He's tackled the pidfd API (which solves so
many ancient gnarly problems with pid management) in a clean, measured,
and consistent manner. He and Aleksa have diligently worked on extensible
syscalls, which solve years of headaches over code maintainability, and
Christian regularly adds kernel selftests. I think he's absolutely got the
best interests of other developers (and users) in mind. Certainly none
of us are perfect, but your statement feels way way off base to me.

> 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.

I think you both want the same thing (generally awesome Linux,
specifically sane and safe namespaces), and I think you're both deeply
involved in the namespace code and the use-cases, so it seems natural
to me that you'd have some form of shared maintainership. To that end, I
hope this can get sorted out. I'd like to have a tree I can count on to
have patches reviewed (and hopefully landed) that touch these areas.

To me, it seems like there has just been an impedance mismatch on the
expectations/priorities of communication speed. I don't see bad
motivations here at all.

> > [...]
> > +T:     https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/
> > +T:     https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/

Obviously y'all still need to finish this discussion, I but I'd expect a
single tree at the end of the day. No other subsystem has multiple trees
that I can find:

$ git grep -A1 ^T: -- MAINTAINERS  | grep -- -T: | wc -l
0

And please use the "git" format for T: so you can specify branches,
which helps immensely in tracking down "latest" commits:

T: git git://URL/TREE.git BRANCH

No other trees use a bare https schema:

$ git grep ^T: -- MAINTAINERS | grep "git " | wc -l
632
$ git grep ^T: -- MAINTAINERS | grep -v "git "
MAINTAINERS:T:  quilt http://people.redhat.com/agk/patches/linux/editing/
MAINTAINERS:T:  quilt http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/
MAINTAINERS:T:  hg http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot
MAINTAINERS:T:  quilt https://ozlabs.org/~akpm/mmotm/
MAINTAINERS:T:  quilt https://ozlabs.org/~akpm/mmots/
MAINTAINERS:T:  git://git.infradead.org/nvme.git
MAINTAINERS:T:  git://git.infradead.org/nvme.git


-- 
Kees Cook

Re: [PATCH] MAINTAINERS: add namespace entry

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

On 2020-08-25, Eric W. Biederman <ebiederm@xmission.com> wrote:
> 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.

Eric, with all due respect, Christian is not a sleeper agent of some
shadow Ubuntu kernel team that is tirelessly trying to slip things by
you. I have no idea where you could have possibly gotten this
impression, given his track record of the past few years.

I also don't understand why you feel the need to talk about things which
he had nothing to do with -- what relationship does the /etc/shadow
thing have to do with his work and track record? Were Debian kernel
contributors considered untrustworthy because of the OpenSSL weak keys
issue? Would it be fair to question your competence because some RHEL
kernel backports were borked? Of course not -- that would be ridiculous!

> 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.

What gives you that impression? This whole thing seems incredibly
strange -- we've all met IRL several times, and have had many long
discussions about the best way to solve problems without placing undue
burden on kernel maintenance.

Furthermore, I don't think this is an acceptable way to talk about a
peer within the kernel community -- attributing malicious intent without
any justification other than "I feel this is the case" is little more
than a character assassination, and I don't see why you would feel that
such a statement is justified.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]