[lxc-devel] [PATCH] lxc-attach: elevate specific privileges
Serge Hallyn
serge.hallyn at ubuntu.com
Wed Nov 20 15:35:51 UTC 2013
Quoting Nikola Kotur (kotnick at gmail.com):
> On Tue, 19 Nov 2013 15:48:36 -0600
> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>
> > Quoting Nikola Kotur (kotnick at gmail.com):
> > > There are scenarios in which we want to execute process with
> > > specific privileges elevated.
> >
> > thanks for submitting this patch. No objection overall, however
> > there are a few existing places where elevated_privileges is set to 1
> > which you are not updating.
>
> Thanks for the review and for catching this. I will update the patch
> and resend it (along with a signed-off-by).
>
> > I also notice that currently it seems broken as the manpage says that
> > -R should imply -e, but i don't see where that is enforced any more.
>
> Actually, it's not -R that implies -e, it's the -s option (specifying
> which namespaces to attach to).
Well huh. I was sure I saw a comment about -R implying -e, but I
don't see it now, so that's fine :)
> And if you have a bit of time I'd appreciate if you could explain why
> should we elevate privileges for attaching to specific namespace? Seems
> to me that it is unrelated, since I should be able to enter NETWORK ns
TBH I'm not sure. It was like that since the start of the -s feature,
which is commit e13eeea2db3743bf8d3fe2833e069a80e2c4102c, but I don't
see the rationale for it in the git history or mailing list. Christian?
> while not elevating cgroup, for example?
I haven't thought it through, but I could imagine it being a problem if
attach tries to enter you into the container's LSM domain while you're
only in its ipc namespace. You might not (with a strict selinux policy)
be able to read any host files, and therefore execute anything. But I
suspect there's a simpler rationale.
-serge
More information about the lxc-devel
mailing list