short answer: i solved this problem by explicitly setting auth_unix_ro = “none” auth_unix = “none” in the libvirtd.conf file, and not using policy kit for access, but using standard unix permissions instead.
longer answer and request: i first downloaded the source for libvirt and compiled it with bus support (—with-dbus) and installed and tested it. policy kit then works as it did before the change to the 1.2.x series libvirt.
i then went back and re-read the configuration option text in the libvirtd.conf file and snapped to the statement that if polkit was compiled in (which it is in version 1.2.10) then the default on the auth_unix directive will change from “none” as shown in the comment to “polkit”, which in libvirt 1.2.10 wants to use DBus, hence the error. explicitly setting the directive to “none” disables the polkit access control and solves the DBus error, although at the sacrifice of some fine grained control.
request: since centos 6 has DBus support, can the maintainer of the libvirt package enable DBus support in the build, so we can use polkit access control?
thanks…
r.
On Mar 23, 2015, at 21:45, rgritzo rgritzo@gmail.com wrote:
this is the same problem that i started chasing back in january, and posted in the mailing list under the topic: libvirt errors after applying RPMS from 2015:X002, last message in the thread is here: http://lists.centos.org/pipermail/centos-virt/2015-February/004247.html http://lists.centos.org/pipermail/centos-virt/2015-February/004247.html
i have more information here, and am re-posting hoping to get some new insights.
btw - this is on centos 6.6, kernel 3.10.68-11.el6.centos.alt.x86_64.
i have a policy kit (.pkla) local authority file that should allow a specific user access to manage xen domains, but that seems to be failing:
[user@centos ~]$ virsh -c xen:/// xen:/// error: failed to connect to the hypervisor error: internal error: DBus support not compiled into this binary [user@centos ~]$
this behavior started with the updates applied as a result of the 2015:x002 advisory.
after another day of troubleshooting, with an older machine that has not been patched side by side with the fully updated system, i think i have tracked it down to the update from libvirt-0.10.2.8-9.el6.centos.alt.x86_64 (and related dependencies) to libvirt-1.2.10-3.el6.x86_64.
it seems like with the older libvirt and virsh 0.10.2.8 the policy kit authority file would grant access to virsh to manage Dom0 and DomU just fine, but with the switch over to libvirt-1.2.10 (and virsh 1.2.10) something changed, and now not only does the policykit not work, but flags the ‘DBus support’ error above. running virsh with sudo, or as a privileged user, works just fine. but trying to run it as a non-privileged user, granting access through policy kit, fails.
in reviewing the changelogs for libvirt it seems that a patch was applied in late 2014 that changed the libvirt polkit code to use the DBusAPI instead of the pkcheck CLI helper - so i am guessing this is where the DBus reference in the error message comes in? this DBus API change was applied to libvirt 1.2.9, so i am assuming it came in with the upgrade to libvirt-1.2.10.
which brings me around full circle to the libvirtd error message - which is:
2015-03-24 02:51:36.550+0000: 5777: error : virDBusGetSystemBus:1742 : internal error: DBus support not compiled into this binary
i reviewed the build log for libvirt at http://cbs.centos.org/kojifiles/packages/libvirt/1.2.10/3.el6/data/logs/x86_... http://cbs.centos.org/kojifiles/packages/libvirt/1.2.10/3.el6/data/logs/x86_64/build.log and indeed i see: configure: dbus: no
so that seems consistent.
i see some patches to libvirtd in august of 2013 that refer to the daemon having a fallback method for those systems that don’t support DBus.
is there some mechanism in libvirtd to allow the policy checks to work without dBus - and if so any ideas as to either a) why they are not working, b) how to enable / fix this?
thanks again for your patience on this…
r.
-- rgritzo at gmail.com http://gmail.com/