How to start contributing to namespaces in the kernel.

Eric W. Biederman ebiederm at xmission.com
Mon Dec 29 21:14:23 UTC 2014


I was just asked how to start contributing to namespaces in the kernel
and my reply is generic to anyone so I am making it public in the hopes
it is of use to more people.

Timothy Chen <tnachen at gmail.com> writes:

> Hi Eric,
>
> My name is Timothy Chen and I work a lot on Mesos/Docker/Rocket that
> all utilizes namespaces.
>
> I'm looking to contribute to Namespaces in the Kernel and besides
> knowing where the code is I don't actually have much idea what the
> process is like and what issues I can start looking at.
>
> I see you're the main person working with Namespaces so I wonder if
> you can point me to where I can start learning how the patch process
> work for namespaces, and what issues/bugs I can look at to start off
> with?

You will want to follow the containers mailling list:
http://lists.linuxfoundation.org/mailman/listinfo/containers

The standard reference for the kernel process is:
https://www.kernel.org/doc/Documentation/SubmittingPatches
(also found in the kernel git repo under Documentation).

Priorities are set by enlightend self interest.  Aka you see a problem
that you understand, and care about and you submit a patch. 

In most cases this involves working with the upstream maintainer of
whatever subsystem the namespaces is for.   Aka all networking patches
go through David Miller.  I tend to review namespace specific issues so
I would appreciate a Cc.

There are some outstanding issues and outstanding patches that I am a
little behind on, as I was away from the kernel for quite a few months
on a job hunt earlier this year.  Hopefully in the next couple of weeks
I will finish getting that backlog cleared up.

Developing namespace code is simultaneously simple and very difficult.
On a good day a namespace is just an extra layer of indirection where
you have to look up a name.  On a bad day the entire subsystem has to be
rewritten so that extra layer of indirection can be supported in a clean
way without hacks.  The general case always has to be solved for
namespace patches to be interesting in upstream, and with a kernel that
is going on 23 years old that can be a lot of cases to consider in some
cases.

>From my perspective namespaces are essentially complete.  There are a
few little things around the edges (as there always will be) that need
work, but there are core seems pretty solid.  The things I am aware of
right now are:
- netlink passable ids for network namespaces
- unprivileged mounts of filesystems (with the user namespace)
- cgroup namespaces (aka getting cgroups and containers to play nice).
- unprivileged cgroups (aka making chmod on a cgroup file not exploitable).
- nested networking or making it reasonably easy to support containers
  in a data center, and easy to support multiple containers on one
  machine.
- devices in containers - Usually this is just dealing with the fact
  that there are no proper abstractions for a class of devices and
  figuring out how to deal with that.

My priorities are getting security issues cleared up (especially with
user namespaces) and then getting a little feature work done so that
more things can be done safely in user namespaces without privilege
(especially filesystem mounting).

The process for features is that when figuring out what to do and where
to start we have conversations (generally publicly) and then write the
code and implement.  Patches always make features ideas much more
concrete and sometimes it can take a while.  As part of making progress
I wound up needing to rewrite sysfs and sysctl and significant parts of
proc, so the result would be clean and maintainable.  Conversations also
need to be had with not just container folks but also people who
maintain the affected subsystems.  So sometimes despite the result being
comparatively simple easy to follow code, the road to get there can be
long.

Good luck and I hope you can find an itch in the kernel namespaces code
you can succesfully scratch.

Eric


More information about the Containers mailing list