On Wed, Aug 08, 2007 at 03:42:30PM +0100, Richard W.M. Jones wrote: > 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 That either gives a user full access without requiring any password, or requires that the app run as root. That's just a mild tweaking of the status quo. It doesn't allow us to authenticate a non-root user to allow them access without the app itself being run as root. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list