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. But there are plenty of legitimate cases in which you would not want a userns. > 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 No I like it for giving a nice way to share host fs with containers without relying on ro bind mounts. > 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. _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
