On Thu, Oct 29, 2020 at 8:39 PM Michal Privoznik <mprivozn@xxxxxxxxxx> wrote:
On 10/29/20 4:47 PM, Natxo Asenjo wrote:
> ah, yes. I try this:
>
> $ virsh -c qemu:///system
>
> But it then I get a prompt:
>
> ==== AUTHENTICATING FOR org.libvirt.unix.manage =============
> System policy prevents management of local virtualized systems
> Authenticating as: sudo_user_not_disclosed
> Password:
> Password:
> polikit-agent-helper-1: pam_authenticate failed: Authentication failure
>
> Our allowed groups in the /etc/dbus-1/system.d/org.libvirt.conf are no
> sudo users (this can change, but not as of now). It is a bit strange
> that the get the password prompt for a local sudo user we have in place
> for as systems have no working sssd connection to the idm realm (break
> glass user)
>
> My user can use the system bus in cockpit without a password.
>
> The dbus policy looks like this:
>
> <policy group="groupname">
> < allow send_destination="org.libvirt"/>
> </policy>
> <policy group="other_groupname">
> < allow send_destination="org.libvirt"/>
> </policy>
This is expected. qemu:///system uses an unix socket to talk to libvirtd
and not dbus. I don't know what credentials does cockpit set there.
But I'm not sure it's safe to go behind cockpit's back and talk to
libvirt directly. If you'd change a configuration of a VM it may not be
reflected in cockpit.
to be honest, I found about the dbus system connection policies in the cockpit documentation, the have a link to the libvirt dbus snippet page:
So is it not possible (taking cockpit out of the equation) to allow virsh to run as a normal user to connect to the local system connection?
--
regards,
Natxo
--
--
Groeten,
natxo
Groeten,
natxo
