[libvirt] ACLs for libvirt

[Daniel Veillard]

On Wed, Nov 23, 2011 at 12:27:27PM -0500, Dave Allan wrote:
> On Wed, Nov 23, 2011 at 06:17:46PM +0100, Michal Privoznik wrote:
> > Hi all,
> > 
> > I'd like to implement this new feature for libvirt. However, I think we
> > should settle down on design first. My biggest concern is choosing the
> > right level on on which ACLs will be implemented. Should be interested
> > only in (user, API), or with more granularity (user, API, API's parameters)?
> > Or should we take the RBAC path?
> > How should we even identify and authorize users?
> > 
> > My initial though is to create framework which can be used then to
> > implement ACLs on any level we want.
> 
> My $.02 is that this has the potential to be such a huge project that
> we need to come up with a design that lets us bite off as much as we
> want at one time, leaving the rest of libvirt's functionality
> operating as it always has.  So, for example, we could start by
> creating an ACL that would let a particular user boot and shutdown but
> not edit a VM; later when we wanted to let particular users connect to
> the VM's console, we could implement that, and so on.  It needs to be
> done in a consistent way so that future additions are clearly slotted
> into the existing design.

I tend to agree, I think like for the security module, we should provide
an access control driver API with exhaustive parameters, but as a first
step implement a simple user based driver. We just need to make sure
that it would allow to implement a full RBAC kind of driver.
 It seems to me that the driver just need to plug in the API entry
points, i.e. mostly libvirt.c.
 I would probably not pass all APIs parameters at the API level
but some function ID, and main arguments:
   - connection
   - domain
   - network
   - interface
   - pool
   - vol
   - device
   - snapshot
   - secret
   - stream
   - ...
   - and some kind of string (could be used for xml, uuid, device path, or
     migration URI for example)

 The first use of that driver could be to implemenent the read-only
mode of connections internally. Might indicate that being able to
stack multiple access control driver as an interesting feature (i.e.
how to finer restrict read-only mode with extra rules).

  I think a lot of the code in the driver front-end should be fairly
mechanical ... dunno if we should generate it from the API description
though, just an idea.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/