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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list