Great, thanks for pointing this out. I will certainly look at it.2018-05-09 14:41 GMT+03:00 Daniel P. Berrangé <berrange@redhat.com>:On Wed, May 09, 2018 at 10:00:19AM +0100, Daniel P. Berrangé wrote:
> On Wed, May 09, 2018 at 11:50:33AM +0300, Anastasiya Ruzhanskaya wrote:
> > Here https://libvirt.org/acl.html is stated that you designed this access
> > control system as pluggable. Are there any options ( even with modifying
> > libvirt code) to plug in any custom driver?
> > I just need to take a try and design something that will support remote
> > access control.
> > I am not sure if sVirt is the right thing I should look at.
>
> It is pluggable in the sense that we can write more backends for it
> without having to refactor the rest of libvirt codebase. It isn't
> pluggable from POV of an end user wishing to change it - it needs
> contribution to libvirt code to add more options.
>
> I did look at creating an SELinux plugin many years ago, but the
> number of new SELinux AVs to be defined was huge and I wasn't sure
> the complexity of policy would be practical to handle in real world.
> Also, SELinux with TCP adds an extra level of complexity as you now
> need to figure out IPSec setup to pass SELinux labels across the
> network from the client.
>
> Probably what we would more usefully add is a simple RBAC based
> module natively in libvirt.
I forgot to say that if you want to look at writing a new impl the code
is kept in $GIT/src/access/.
The current polkit impl is viraccessdriverpolkit.c. Implementing a new
driver involves creating a new source file with a virAccessDriver
struct that contains pointers to the methods that implement the desired
logic.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|