On Fri, Nov 25, 2011 at 11:35:54AM +0800, Daniel Veillard wrote: > On Thu, Nov 24, 2011 at 09:45:44AM +0000, Daniel P. Berrange wrote: > > > In addition "API" is really the wrong level of granularity for expressing > > > the checks. Several separate APIs will need to be covered under the same > > > check, while at the same time, one API might require multiple checks. > > > > For clarity here are some examples of why you can't do checks at the API > > level, and instead must do it inside each driver > > > > * The virDomainDefineXML API - you need todo two separate checks, one > > if the config does not already exist (eg defining a new guest), and > > another if the config does exist (updating an existing guest). > > Okay > > > * virDomainListDomains API - you need to filter the returned list of > > IDs to only those the user is allowed to view. You can't do the filtering > > if you only have the IDs, so it needs to be done inthe driver > > Here I'm far less convinced. To me the role system influence the API > in saying if you can run the API or not. In that case you want to change > the API output. I'm not sure it's a good idea. If I take the unix > analogy, it's okay to forbid listing directories (even if some files > may be accessible to the user), but changing the directory listing > based on whom does the operation makes an awful lot of things more > complex. I'm not sure we want to do this ! This is actually something that is done in SELinux for directories. If the file is not labelled with a suitable context, it does not apppear when you do 'readdir()'. This filtering is essential if we are able to support the "ISP use case" where multiple users connect to the same libvirtd and must not see each other's domains. > > * virDomainAttachDevice API - need to todo different checks for the > > different types of device being attached & potentially multiple > > checks if the attached device references other host resources. > > eg a PCI device attach with managed=yes, must check that the user > > is allowed to attach a device, and also check that the user is > > allowed to detach & reset host PCI devices. > > If we try to go too fine grained we are likely to make it too hard > to use, I see a risk here. Ok, here's another example. The admin has created a guest for a user and wants to allow the user to change the VNC password in the fly, but not hotplug or unplug disks or network devices. Because the virDomainAttachDevice API is a generic entry point for performing many different actions, we will inevitably need lots of different security checks in this API. Daniel. -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list