[lxc-devel] [PATCH 1/2] allow lxc.cap.keep = none

Dwight Engen dwight.engen at oracle.com
Thu Jun 19 21:58:04 UTC 2014


On Thu, 19 Jun 2014 20:48:27 +0000
Serge Hallyn <serge.hallyn at ubuntu.com> wrote:

> Quoting Dwight Engen (dwight.engen at oracle.com):
> > On Thu, 19 Jun 2014 19:45:14 +0000
> > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > 
> > > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > > On Thu, 19 Jun 2014 16:32:18 +0000
> > > > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > > 
> > > > > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > > > > On Thu, 19 Jun 2014 14:23:40 +0000
> > > > > > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > > > > 
> > > > > > > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > > > > > > Commit 1fb86a7c introduced a way to drop capabilities
> > > > > > > > without having to specify them all explicitly.
> > > > > > > > Unfortunately, there is no way to drop them all, as just
> > > > > > > > specifying an empty keep list, ie:
> > > > > > > > 
> > > > > > > >     lxc.cap.keep =
> > > > > > > > 
> > > > > > > > clears the keep list, causing no capabilities to be
> > > > > > > > dropped.
> > > > > > > > 
> > > > > > > > This change allows a special value "none" to be given,
> > > > > > > > which will drop all capabilities. If "none" and some
> > > > > > > > other valid capability are both specified, the "none"
> > > > > > > > is ignored and the valid capability is kept.
> > > > > > > > 
> > > > > > > > Signed-off-by: Dwight Engen <dwight.engen at oracle.com>
> > > > > > > 
> > > > > > > The way you have this, if I do
> > > > > > > 
> > > > > > > lxc.cap.keep = sys_admin,none
> > > > > > > 
> > > > > > > then sys_admin will not in fact be dropped.  Is that what
> > > > > > > we want, or do we want 'none' to be an absolute?
> > > > > > 
> > > > > > Yeah, I'm not sure, which is why I mentioned that behavior.
> > > > > > Initially I
> > > > > 
> > > > > Sorry I see that now :)
> > > > > 
> > > > > > thought the syntax maybe should just be
> > > > > > 
> > > > > >   lxc.cap.keep =
> > > > > > 
> > > > > > but that would require adding a flag to the logic to know
> > > > > > that we'd seen a .keep (since the list would be empty) and
> > > > > > gives it a meaning other than just "empty the keep list".
> > > > > > Adding a none was a simple way to get us into the .keep
> > > > > > logic instead of the .drop logic. Another alternative is to
> > > > > > just not allow none and any other cap. I'm fine to
> > > > > > implement whatever way we think makes the most sense.
> > > > > 
> > > > > To me making none always drop all seems to make more sense.
> > > > 
> > > > Sounds good to me, but just to make sure I'm clear before I
> > > > implement it :) If there is a none in the list, regardless of
> > > > order, then all will be dropped? So
> > > > 
> > > >   lxc.cap.keep = none,sys_admin
> > > > 
> > > > drops all?
> > > 
> > > No.  I mean the way you have it there would sort of suggest the
> > > answer should be yes, but if an included common config file has
> > > 
> > > lxc.cap.keep = none
> > > 
> > > I may want to override that in my container's own config.
> > 
> > So in this case you want sys_admin to override none ...
> >  
> > > That is the same reason for my original request - if the common
> > > config file has
> > > 
> > > lxc.cap.keep = sys_admin
> > > 
> > > and I put
> > > 
> > > lxc.cap.keep = none
> > > 
> > > in my local container config, then I want 'none' to win out.
> > 
> > ... but in this case you want none to override sys_admin. So I think
> > you want order to matter, ie whatever is specified last wins? To do
> 
> Right.  Our commonized config layout wants that.
> 
> > 'last wins', we could clear the list and put none in it when 'none'
> > is parsed. It looks like the keepcaps list stays in order so this
> > continues to work even after a write_config().

Okay, so doing the above works fine as long as we don't care if we lose
lxc.cap.keep lines that came *before* a keep = none when doing an
lxc-clone. I think that's okay as its akin to losing comments, and there
is other stuff we don't carry through a clone yet despite aliens :)

> > > Am I making sense?
> > 
> > I think so, lets see if I got it this time :)
> >  
> > > -serge
> > > _______________________________________________
> > > lxc-devel mailing list
> > > lxc-devel at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-devel
> > 
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel



More information about the lxc-devel mailing list