Support running runc as non/less privileged user

[discordianfish]

Right now runc requires to be run as root where technically it should be possible to run containers as unprivileged user (at least if user namespaces are used)

[cgwalters]

See also https://git.gnome.org/browse/linux-user-chroot/tree/README
which supports use by unprivileged users even without user namespaces.

See discussion about use of PR_SET_NO_NEW_PRIVS (which is enforced by seccomp) and additional note about local DoS attacks.

[LK4D4]

We just need to reconsider some default mounts for this to work I think, maybe drop /proc readings in init.

[chrisgorgo]

This allow containers to be used in shared computing environments such as HPCs. Very exciting!

[zeneofa]

I would be very interested to find out how/when this is implemented, especially as it may help me create a transferable environment to use in HPC environments, as there I have no sudo and no chance to install docker.

[discordianfish]

So science is interested. Now we need enterprise so somebody will actually start working on this ;)

[davidlt]

+1 from HEP (High Energy Physics) community. You can have your hundreds of thousands of cores even with a common operating system like RHEL/CentOS/Scientific Linux, but you still end with Android-like fragmentation because all computing centres do updates on their schedules. When you send your job to various computing centres you also want to provide your container as environment. Preferably that runs as unprivileged container. The container protects you from the fragmentation and you don't get magic differences due for example due to update of libm.

HTCondor bash system already have some support for Docker: https://research.cs.wisc.edu/htcondor/HTCondorWeek2015/presentations/ThainG_Docker.pdf

[wking]

On Wed, Oct 07, 2015 at 12:27:24PM -0700, davidlt wrote:

HTCondor bash system already have some support for Docker:
https://research.cs.wisc.edu/htcondor/HTCondorWeek2015/presentations/ThainG_Docker.pdf

Page 29 of those slides shows the host's sysadmin starting a Docker
service.

More generally, I'm not sure how this is going to work for
unprivileged users. namespaces(7) 1 has:

Creation of new namespaces using clone(2) and unshare(2) in most
cases requires the CAP_SYS_ADMIN capability. User namespaces are
the exception: since Linux 3.8, no privilege is required to create a
user namespace.

So an unprivileged user should be able to create a user namespace,
and have some flexiblity inside it. However, you don't have complete
flexibility (to avoid things like 2). I'm not sure if you'd have
enough flexibility to run a useful bundle, but I guess we'll see ;).

Doing something like making runc setuid-root would be a bad idea,
because the caller could use pre-start hooks (for example) to perform
any action they wished with the elevated permissions.

[davidlt]

We disallow software to be setuid-root or installed as root. I love the way runc is now, seems to be a single capable binary, no need for special accounts, no need for some daemon. The only thing that's missing is ability to use it without root account.

[wking]

On Fri, Oct 09, 2015 at 12:23:32AM -0700, davidlt wrote:

We disallow software to be setuid-root or installed as root…

Most (and hopefully all ;) setuid-root programs are that way because
they need those elevated permissions to accomplish their task. The
question is whether runC can launch all OCI-compliant bundles, or a
useful subset of those, or nothing useful at all without needing those
elevated permissions.

[davidlt]

Then maybe the question is: what do we loose if we take away root permissions from runC on RHEL6, RHEL7 and mainline kernels?

IIRC LXC supports unprivileged containers on 3.12 and above kernels. Docker should have support for user namespaces in 1.9 according to PR I managed to find.

We have ~170 computing centres connected and that's how you achieve high number of cores to process big data. Currently they are running RHEL 6.X/CentOS 6.X/Scientific Linux 6.X. They will be moved to 7.X soonish, I believe. There are a few cases people migrated to 7.X and just use full-system-container with LXC and RHEL 6.X rootfs.

Now image (rootfs) and runC binaries distribution to all computing centres is an easy task. At this point I didn't need to involve administrators from all computing sites (no need for special users, no daemons, etc.). But now, I cannot use it because you don't have root permissions.

Preference would have everything centralised where you don't have to involve ~170 people to do the right job, which then would take weeks to months to setup.

[dqminh]

To be able to run this as non-privileged user, user namespace is just one of the problems. I think we also need to look at some improvements on the way we are handling cgroups right now as that requires root permission.

AFAIK, unprivileged lxc used a privileged cgmanager daemon to handle its own cgroup assignment.

[davidlt]

That's correct.
https://linuxcontainers.org/cgmanager/introduction/

What's CGManager? 
CGManager is a central privileged daemon that manages all your cgroups for you 
through a simple D-Bus API. It's designed to work with nested LXC containers 
as well as accepting unprivileged requests including resolving user namespaces UIDs/GIDs.

[mr-c]

Hello,

For scientific computing (where one is running relatively "normal" POSIXy applications) the Common Workflow Language is trying out a solution for rootless containers: https://github.com/common-workflow-language/common-workflow-language/wiki/Userspace-Container-Review#getting-userspace-containers-working-on-ancient-rhel

A bit of a hack, but no root, weird kernel, or suituid binary is needed. Obviously one should use a more mature approach, but for the many academic clusters running older kernels this should suffice until they can upgrade.

[idea by @mr-c, proof of concept by @kdmurray91]

The CWL anxiously awaits a mature and well adopted open containers standard so please steal this idea and run with it :-)

[chrisgorgo]

Couple more interesting projects trying to solve this problem:

• http://gmkurtzer.github.io/singularity/ - capturing binary dependencies in portable manner
• https://bitbucket.org/berkeleylab/shifter - running Docker images HPCs in a secure manner

[mr-c]

Note that shifter uses (real) chroot and thus requires root.