[lxc-devel] Resetting the supplementary groups

[Stewart Brodie]

Serge Hallyn <serge.hallyn at ubuntu.com> wrote:

> Quoting Stewart Brodie (sbrodie at espial.com):
> > 
> > A feature that I need is to be able to set the supplementary groups so
> > that when I start an unprivileged container, the initial user in the
> > container is a member of a number of supplementary groups, so that it
> > will have access to various places in the filesystem protected via group
> > ownership.  Since
> 
> So to be clear, you're running containers without a user namespace, and
> dropping all capabilities?

I'm running several containers - most with a separate user namespace, a few
without.  All drop as many capabilities as possible.

This is being done to keep multiple applications almost entirely isolated
from each other, with just a very few well-defined, controlled
communications channels set up between them.  Most of these involve UNIX
domain sockets, bind mounted into the container's filesystem with access
protected by group ownership of the directory.  So it is important that
nothing inside the container can grant itself membership of additional
groups - hence no CAP_SETGID.

Of course, ideally, they wouldn't be visible at all inside the container's
filesystem, but there are other odd technical reasons why that doesn't work
for me that I'd rather not go into, as it'd be quite long and complicated
and not really relevant here.


> > inside the container nothing has any capabilities and the bounding set
> > is empty, there is no way for me to change groups as the setgroups()
> > call always fails, so it needs to be set from outside.  Currently,
> > lxc/start.c empties the supplementary groups if it's an unprivileged
> > container.
> > 
> > I'd like to be able to declare them in the container configuration file.
> > I'd also like to be able to set them on privileged containers for
> > consistency.
> > 
> > So I made a patch that adds this feature which works well enough for me.
> > 
> > Would anybody else find this useful?
> 
> Doesn't fit into my own use cases but that's ok, so just go ahead
> and send the patch and we can discuss.

OK, I'll have a go.

I realise my use case is somewhat specialised.  Perhaps the eventual right
solution for me is to not use lxc at all, but drive everything myself at a
lower level to retain fine-grained control where it's needed.  However, I
really like that lxc provides a great deal of flexibility with simply
understood configuration files that allow for easy experimentation.


-- 
Stewart Brodie
Senior Software Engineer
Team Leader ANT Galio Browser
Espial UK