Quoting Stéphane Graber (stgra...@ubuntu.com):
...
> I'm also wondering, what's the state of lxc-attach wrt user namespaces?
> does it need any updating too?
I need to check that still - I'm not sure.
> > @@ -1221,7 +1221,7 @@ static int setup_kmsg(const struct lxc_rootfs *rootfs,
> > return 0;
> > }
> >
> > -static int setup_cgroup(const char *name, struct lxc_list *cgroups)
> > +int setup_cgroup(const char *name, struct lxc_list *cgroups)
>
> Why the change?
Because setup_cgroup now has to be done by the parent in start.c. When
not starting a new user namespace, the child task has a period of time
after the clone(CLONE_NEWNS|...) where it is still root and able to
set up cgroups. But when doing clone(CLONE_NEWUSER) then it immediately
is unable to do so, so we now have the parent do it after it knows
the child has been cloned.
> > - if (setup_caps(&lxc_conf->caps)) {
> > - ERROR("failed to drop capabilities");
> > - return -1;
> > + if (lxc_list_empty(&lxc_conf->id_map)) {
> > + if (setup_caps(&lxc_conf->caps)) {
> > + ERROR("failed to drop capabilities");
> > + return -1;
> > + }
> > }
>
> Why can't we drop capabilities in a user namespace?
We can, but we don't need to. Root in the new namespace can run with
all capabilities since the capabilities are targeted to resources owned
by the container{
-serge
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
