Bug 957300 - Add polkit rules allowing users in a specific unix group to not require password
Summary: Add polkit rules allowing users in a specific unix group to not require password
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-04-27 00:30 UTC by William Brown
Modified: 2016-05-14 09:00 UTC (History)
18 users (show)

Fixed In Version: libvirt-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-23 09:10:35 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1187019 0 low CLOSED Avoid polkit password prompts 2021-02-22 00:41:40 UTC

Internal Links: 1187019

Description William Brown 2013-04-27 00:30:20 UTC
Description of problem:
When running libvirt from virt-manager, or remotely via ssh, one must authenticate via policykit to be granted access. This however, over SSH, does not work without adding policykit rules (That are somewhat awkward to find in my experience) or for virt-manager, it creates needless virt-manager password prompts.

To make it more accessible to users, a policykit rule allows members of the qemu group access should be added: such as

polkit.addRule(function(action, subject) {
        if (action.id == "org.libvirt.unix.manage" &&
                subject.isInGroup("qemu")) {
                return polkit.Result.YES;

This lowers the bar to using libvirt, increases accessibility and makes it easier to administer. People can choose to ignore the qemu group and continue to use the polkit authentication window - This just means that people who wish to locally or remotely manage machines need to be added to the qemu group.

Comment 1 Cole Robinson 2013-06-11 21:11:50 UTC
Honestly I'd be happy with this too. Many many people install custom polkit rules to do effectively the same thing, but as a one off for their username of choice. My understanding is that Ubuntu does (or did at one time) do something similar with a 'kvm' group.

I've floated the idea upstream: https://www.redhat.com/archives/libvir-list/2013-June/msg00503.html

Comment 2 Daniel Berrangé 2013-06-18 16:07:01 UTC
Allowing members of the 'qemu' group to access libvirt without a password would be a huge security whole. The 'qemu' group is running the QEMU/KVM processes for each VM. So such a polkit rule would allow a compromised QEMU process to access libvirt & thus compromise the entire host.

Comment 3 Cole Robinson 2013-06-18 16:58:19 UTC
I'm more interested in the general idea, the group could be named 'foobar' for all it matters.

Comment 4 William Brown 2013-06-19 05:46:09 UTC
Perhaps the group could be called virtadm then? Similar to the "adm" admin group.

Comment 5 Daniel Berrangé 2013-06-19 14:17:38 UTC
Should probably just use 'libvirt' as a group name.

Comment 6 Cole Robinson 2013-12-16 19:56:12 UTC
Still relevant on F20

Comment 7 William Brown 2014-05-08 03:37:57 UTC
Any movement on this?

Comment 8 Dave Allan 2014-05-08 13:43:18 UTC
Hi William, since you're the person with the most stake in this question, you should reopen discussion Cole started upstream on libvir-list and drive it to a conclusion.  I can't predict how the community will react, but from the comments above and the response to Cole's mail, it sounds like the qemu group is not acceptable, but the libvirt group might be.  Just my $.02.

Comment 9 Marcelo Ricardo Leitner 2014-05-24 15:00:32 UTC
+1 on this one, as I've doing similar setup myself on my hosts for the same reasons.

Comment 10 Cole Robinson 2015-03-31 19:26:16 UTC
Clearing needinfo. I think this idea would be accepted but someone needs to submit a patch or start a discussion on libvir-list. I might get to it for F22 cycle but no guarantees

Comment 11 Cole Robinson 2015-04-28 23:53:46 UTC
I sent a patch upstream for this, using the group 'libvirt' :


Comment 12 Cole Robinson 2015-05-04 17:03:48 UTC
Upstream now:

commit e94979e901517af9fdde358d7b7c92cc055dd50c
Author: Cole Robinson <crobinso>
Date:   Tue Apr 28 17:38:00 2015 -0400

    polkit: Allow password-less access for 'libvirt' group
    Many users, who admin their own machines, want to be able to access
    system libvirtd via tools like virt-manager without having to enter
    a root password. Just google 'virt-manager without password' and
    you'll find many hits. I've read at least 5 blog posts over the years
    describing slightly different ways of achieving this goal.
    Let's finally add official support for this.
    Install a polkit-1 rules file granting password-less auth for any user
    in the new 'libvirt' group. Create the group on RPM install

Comment 13 William Brown 2015-05-06 01:30:50 UTC
Thank you for getting back to this and making it happen! Much appreciated.

Comment 14 Fedora Update System 2015-06-06 17:57:38 UTC
libvirt- has been submitted as an update for Fedora 21.

Comment 15 Fedora Update System 2015-06-07 16:02:01 UTC
Package libvirt-
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 16 Kamil Páral 2015-06-17 08:02:28 UTC
This is great. Works. Thanks, folks.

Comment 17 Fedora Update System 2015-06-23 09:10:35 UTC
libvirt- has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Laszlo Ersek 2016-05-14 09:00:09 UTC
Found out about this BZ via <http://blog.wikichoon.com/2016/01/polkit-password-less-access-for-libvirt.html> (federated on planet.virt-tools.org).

I just checked, and this feature also made RHEL-7.2, through bug 1194593 (rebase to then-current upstream libvirt, 1.2.16, then to 1.2.17). Awesome, thanks a lot Cole!

Note You need to log in before you can comment on or make changes to this bug.