virsh rights voor normal users
hi, using the cockpit web ui and with these instructions: https://libvirt.org/dbus.html#usage we allow successfully that a group of users can access the console of the system vms in different kvm hosts. Oddly enough, in the same cockpit web interface I can use a terminal, and if I run virsh list --all I get an empty listing. So using cockpit I can manage the system vms, but I cannot use virsh. This is in a rhel 7.8 system. The host is joined to an Idm realm, and this realm has a trust to an AD forest. The users are AD users mapped to an external Idm group. Any ideas as to what we do wrong? Thanks! -- regards, Natxo
On Thu, Oct 29, 2020 at 04:13:45PM +0100, Natxo Asenjo wrote:
hi, using the cockpit web ui and with these instructions:
https://libvirt.org/dbus.html#usage
we allow successfully that a group of users can access the console of the system vms in different kvm hosts.
Oddly enough, in the same cockpit web interface I can use a terminal, and if I run virsh list --all I get an empty listing.
So using cockpit I can manage the system vms, but I cannot use virsh.
This is in a rhel 7.8 system. The host is joined to an Idm realm, and this realm has a trust to an AD forest. The users are AD users mapped to an external Idm group.
Any ideas as to what we do wrong?
There are two distinct instances of libvirt - system mode and session mode. I suspect cockpit is using a different instance than your virsh command https://libvirt.org/drvqemu.html#securitydriver virsh defaults to "session" mode if running non-root, "system" mode if running as root. You can use "-c URI" to override the default if running non-root. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Oct 29, 2020 at 4:25 PM Daniel P. Berrange <dan@berrange.com> wrote:
if I run virsh list --all I get an empty listing.
So using cockpit I can manage the system vms, but I cannot use virsh.
This is in a rhel 7.8 system. The host is joined to an Idm realm, and
On Thu, Oct 29, 2020 at 04:13:45PM +0100, Natxo Asenjo wrote: this
realm has a trust to an AD forest. The users are AD users mapped to an external Idm group.
Any ideas as to what we do wrong?
There are two distinct instances of libvirt - system mode and session mode. I suspect cockpit is using a different instance than your virsh command
https://libvirt.org/drvqemu.html#securitydriver
virsh defaults to "session" mode if running non-root, "system" mode if running as root. You can use "-c URI" to override the default if running non-root.
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>
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. Michal
On Thu, Oct 29, 2020 at 8:39 PM Michal Privoznik <mprivozn@redhat.com> 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: https://cockpit-project.org/guide/latest/feature-virtualmachines 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
On Thu, Oct 29, 2020 at 11:34:09PM +0100, Natxo Asenjo wrote:
On Thu, Oct 29, 2020 at 8:39 PM Michal Privoznik <mprivozn@redhat.com> 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.
It is safe to do everything to the system what cockpit does as cockpit is stateless and can users can jump between terminal and the cockpit UI.
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:
https://cockpit-project.org/guide/latest/feature-virtualmachines
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?
It is possible to allow virsh to connect to system connection by default, you just need to create a new file: $HOME/.config/libvirt/libvirt.conf with this single line in it: uri_default="qemu:///system" for more details see [1]. Pavel [1] <https://libvirt.org/uri.html#URI_default>
hi, thanks all for your input. I got it working creating an Idm group 'libvirt' and adding the pertinent AD external groups to this idm posix group called libvirt. Now I can connect to the system bus and watch the serial console of the vm as a normal user. Thanks, -- regards, Natxo
participants (4)
-
Daniel P. Berrange -
Michal Privoznik -
Natxo Asenjo -
Pavel Hrdina