Serge Hallyn <[email protected]> wrote: > Quoting Stewart Brodie ([email protected]): > > Serge Hallyn <[email protected]> wrote: > > > > > Quoting Stewart Brodie ([email protected]): > > > > > > > > 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 _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
