[lxc-devel] Resetting the supplementary groups

[Stewart Brodie]

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

> Quoting Stewart Brodie (sbrodie at espial.com):
> > 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.
> 
> In some cases you could just map only the gids you want to allow access to
> into a user_ns.  Container could still have CAP_SETGID but couldn't setgid
> to any unmapped gid.


I have a vague recollection that there's a limit on the number of mappings
(5?) ... yes, I've just checked the kernel sources and the array seems to be
fixed at 5 entries.  I have a lot of non-contiguous groups to map, so if it
is limited, that wouldn't be sufficient, although I could see if I could
re-order them so that it was.


> But there are plenty of legitimate cases in which you would not want a
> userns.

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

> No I like it for giving a nice way to share host fs with containers
> without relying on ro bind mounts.

OK, I'll give it a try.


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