I guess LXD would not be an option since we are talking about resource constrained devices. The unprivileged user is actually used only for namespacing purposes and not for actual logins. The power user starts a “provisioning/bootstrapping" process as the unprivileged user, which in turn starts the lxc container and performs some additional tasks, e.g. monitoring. The bootstrapping process might not be “trusted” in the sense that it could have bugs, which should not have any adverse effects on the main functionality of the device.
Maybe the problem can be re-formulated: is an unprivileged container owned by an unprivileged user any more safer than an unprivileged container owned by root? Todor > On 17. May 2017, at 01:38, Fajar A. Nugraha <[email protected]> wrote: > > On Tue, May 16, 2017 at 12:21 PM, Dr. Todor Dimitrov <[email protected] > <mailto:[email protected]>> wrote: > My understanding is that the unprivileged user owning the container can still > alter the cgroups, right? > > > > You should really try lxd. e.g. https://linuxcontainers.org/lxd/try-it/ > <https://linuxcontainers.org/lxd/try-it/> , or install it on your own ubuntu > server/vm. > > The use case that we have in mind is to allow an unprivileged user run a > preconfigured container, which configuration is only writable for power > users. Ideally the unprivileged user should not be able to meddle with the > cgroups or even create new containers. > > Is such a scenario feasible to implement using LXC and cgroups? > > > That's what lxd does. Sort of. Some options: > - you create an unpriv container (the default in lxd), then give access to > the container (e.g. ssh keys, root pass of the container, etc) to the user. > They will be able to restart the container and install whetever package they > want, but they can't create another container > > - you create an unpriv container with nesting enabled (which is what the > try-me link does). The unpriv user will have a set of limits (e.g. total disk > space, total memory, etc) which they can use to create containers under it. > > In either way, the container's root user will not be able to alter it's own > cgroup configuration (e.g. /sys/fs/cgroup/memory/memory.limit_in_bytes). > > -- > Fajar > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
