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. 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 _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
