Daniel P. Berrange wrote:
Currently our authentication model for local connections is using the basic UNIX 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 domain socket 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 which socket 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 run as 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