<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Todor</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 17. May 2017, at 01:38, Fajar A. Nugraha <<a href="mailto:list@fajar.net" class="">list@fajar.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, May 16, 2017 at 12:21 PM, Dr. Todor Dimitrov <span dir="ltr" class=""><<a href="mailto:dimitrov@technology.de" target="_blank" class="">dimitrov@technology.de</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">My understanding is that the unprivileged user owning the container can still alter the cgroups, right?</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">You should really try lxd. e.g. <a href="https://linuxcontainers.org/lxd/try-it/" class="">https://linuxcontainers.org/lxd/try-it/</a> , or install it on your own ubuntu server/vm.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Is such a scenario feasible to implement using LXC and cgroups?</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">That's what lxd does. Sort of. Some options:</div><div class="">- 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</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">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). </div><div class=""><br class=""></div><div class="">-- </div><div class="">Fajar</div></div></div></div>
_______________________________________________<br class="">lxc-users mailing list<br class=""><a href="mailto:lxc-users@lists.linuxcontainers.org" class="">lxc-users@lists.linuxcontainers.org</a><br class="">http://lists.linuxcontainers.org/listinfo/lxc-users</div></blockquote></div><br class=""></body></html>