linux-kernel - Re: [PATCH] MAINTAINERS: add namespace entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zh6in140.fsf@x220.int.ebiederm.org>
Date:   Tue, 25 Aug 2020 11:26:07 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     linux-kernel@...r.kernel.org,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Rob Herring <robh@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Containers <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH] MAINTAINERS: add namespace entry


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@...ntu.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@...ssion.com>
> Signed-off-by: Christian Brauner <christian.brauner@...ntu.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@...ntu.com>
> +M:     Eric W. Biederman <ebiederm@...ssion.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@...tlin.com>
>  R:	Richard Weinberger <richard@....at>
>
> base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd