Hi About virsh connect, I think as follows. ========================================================================== //Authorization model of a general user of now// *Local connection* *Remote connection* HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/W | R/W authority | R/O | R/W //Authorization model of a general user of mine// *Local connection* *Remote connection* HV | Xen | QEmu/KVM/etc HV | Xen | QEmu/KVM/etc --------------------------------- --------------------------------- authority | R/O | R/W authority | R/O | R/W # R/W=Read Write R/O=Read Only ========================================================================== In the same way as connection local at the time of remote connection, this revision is the contents which only Xen cannot full control. Thanks, Shigeki Sakamoto. Daniel Veillard <veillard@redhat.com> wrote:
On Wed, Apr 04, 2007 at 09:33:53PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
This issue should be based on libvirt Authorization Model. I do not know libvirt Authorization model. How do you think? or any document exists? Or should be discuss libvirt Authorization Model later?
Well currently this depends on the kind of virtualization used. For Xen normal user access is though the proxy and that's a read-only acces. For KEmu a non priviledged user will only be able to see and control the emulators running under his own user id. The models are very different and it's on a case by case basis, i.e. each driver will have different capabilities. The authorization model is not global.
Daniel
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/