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

[Serge Hallyn]

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().
> 
> > 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