[lxc-devel] [patch 1/5] Add capability interface

[Andrian Nord]

> The advantage of the 'keep' option I see is, like you did, a lot of 
> capabilities removed for the container by default, but with the option 
> to keep it if it's too restrictive.
> 
> drop only : admin has to write the right configuration each time
> drop / keep : default capabilities are dropped but they can be kept by 
> configuration

Defaults are bad, as nobody reads manual pages and changelogs on every
new release (it least, there is no so much of such people ;)). So,
changing defaults will be hard thing. But, also, not too many people
knows, what capabilities are vital for container operations, and which
are not. So, if we are not using defaults - we should describe in full
details all vital capabilities into manual. It could be hard, as we are
not controlling when and why new capabilities could take their place in
kernel. But if we are using defaults, we may say, that we had dropped
everything 'dangerous' and non-vital already, and dropping anything
else should be done, only if user understands what he is doing, so it
will allow to describe only 'default' capabilities set, which is
controlled by us, so we could be sure, that manual will be complete
dispite of changes in kernel.

Also, without config inclusion (I still don't understands why it's bad,
but anyway...) without defaults it would soon became a mess if new
capabilities would be introduced in some incompatible way with older.

I'm against any need of copy-paste for admin, which whould be required
in case of absense of any common-config techniques. So I think, that
defaults are needed. And, they are also needed for cgroups and
devices, in particular.

> On the otherhand, lxc is a low level component supposed to be used with 
> automated script which can generate the right configuration.

Personally, I don't see much sense in such position. I prefer to have
one single packages that wouldn't require any additional scripting
until I'll want to script something in. I suppose that liblxc should be
such low-level component, maybe with 'bash-bindings', i.e. very
primitive set on programs built on liblxc. But current state of most of
lxc-utils are far above primitivity, imo. So, such talks are very
strange for me - you already have non-low-level and one of the most
usable and sophisticated utilities for managing linux containers and
it's much closer to full-featured end-user utities than to primitive set
of 'bash bindings'.