Daniel P. Berrange wrote:
Currently our authentication model for local connections is using the basicUNIX file permissions, possibly with a setuid helper (in Xen case only). It can be summarized as- If app using libvirt is running as root => full access - Else => read only access The latter is enforced by fact that in Xen case libvirt_proxy only has impl for a handful of read only APIs, or in non-Xen case that the UNIX domainsocket for the daemon /var/run/libvirt/libvirt-sock is mode 0700, while /var/run/libvirt/libvirt-sock-ro is 0777 & the daemon enforces based on whichsocket the client connects to. This is good because it allows non-root to at least monitor guest state while requiring root authentication for actually changing state. This is bad because it requires any app which wants to change state to runas root. ie we are required to launch virt-manager as root to gain ability to manage local guests. Problem with this include:- running the entire PyGTK & GTK & X codebase as root is undesirable - no integration with the DBus desktop session (gnome-vfs integartion) - no integration with the GNOME keyring (for VNC server passwords) - redundant (&dangerous) if all you want to do is manage remote libvirt hosts In summary what I really need for virt-manager is - Always run as non-root - Authenticate for local guest management (ie read+write) UNIX domain sockets already provide a way for each end to identify the PID and UID of the other end. This enables the libvirt daemon to determine the identity of the application on the other end. With this information the daemon merely needs to check this identity against some access control policy rules. Where to get/define these rules though ?
I'm unclear as to what problem this is solving that couldn't be solved using Unix users and groups. Add the users who need full access to a Unix group and change the permissions on the r/w socket:
srw-rw---- 1 root virtstaff 0 2007-06-29 15:50 /var/run/libvirt/libvirt-sock
I guess that'd be too simple for people who think XML configuration files are a good idea.
Well, I checked the patch and it is not invasive, nor does it depend on PolicyKit / freedesktop.org crack being available in the future, so I guess we can carry it.
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list