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