[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