As a normal user, 'virsh connect qemu:///system' and
'virsh connect --readonly qemu:///system' will prompt for root password.
If the user is added to the libvirt group, only
'virsh connect --readonly qemu:///system' will prompt for root password.
The libvirt polkit rules already allow libvirt group members access to
the rw socket. Add a rule allowing to access the ro socket.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
---
src/remote/libvirtd.rules | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/remote/libvirtd.rules b/src/remote/libvirtd.rules
index 01a15fac2e..d9be94fcc4 100644
--- a/src/remote/libvirtd.rules
+++ b/src/remote/libvirtd.rules
@@ -1,5 +1,12 @@
-// Allow any user in the 'libvirt' group to connect to system libvirtd
-// without entering a password.
+// Allow any user in the 'libvirt' group to connect to the system libvirtd
+// ro and rw sockets without entering a password.
+
+polkit.addRule(function(action, subject) {
+ if (action.id == "org.libvirt.unix.monitor" &&
+ subject.isInGroup("libvirt")) {
+ return polkit.Result.YES;
+ }
+});
polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage" &&
--
2.29.2
On Mon, Nov 30, 2020 at 05:28:16PM -0700, Jim Fehlig wrote:
> As a normal user, 'virsh connect qemu:///system' and
> 'virsh connect --readonly qemu:///system' will prompt for root password.
> If the user is added to the libvirt group, only
> 'virsh connect --readonly qemu:///system' will prompt for root password.
This doesn't make sense - the readonly case should never prompt for
a password, since libvirtd.polkit.in grants that permission out of
the box. The libvirtd.rules file should just be extending what is
defined in the main libvirtd.polkit file.
>
> The libvirt polkit rules already allow libvirt group members access to
> the rw socket. Add a rule allowing to access the ro socket.
>
> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
> ---
> src/remote/libvirtd.rules | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/remote/libvirtd.rules b/src/remote/libvirtd.rules
> index 01a15fac2e..d9be94fcc4 100644
> --- a/src/remote/libvirtd.rules
> +++ b/src/remote/libvirtd.rules
> @@ -1,5 +1,12 @@
> -// Allow any user in the 'libvirt' group to connect to system libvirtd
> -// without entering a password.
> +// Allow any user in the 'libvirt' group to connect to the system libvirtd
> +// ro and rw sockets without entering a password.
> +
> +polkit.addRule(function(action, subject) {
> + if (action.id == "org.libvirt.unix.monitor" &&
> + subject.isInGroup("libvirt")) {
> + return polkit.Result.YES;
> + }
> +});
>
> polkit.addRule(function(action, subject) {
> if (action.id == "org.libvirt.unix.manage" &&
> --
> 2.29.2
>
>
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 12/1/20 2:17 AM, Daniel P. Berrangé wrote: > On Mon, Nov 30, 2020 at 05:28:16PM -0700, Jim Fehlig wrote: >> As a normal user, 'virsh connect qemu:///system' and >> 'virsh connect --readonly qemu:///system' will prompt for root password. >> If the user is added to the libvirt group, only >> 'virsh connect --readonly qemu:///system' will prompt for root password. > > This doesn't make sense - the readonly case should never prompt for > a password, since libvirtd.polkit.in grants that permission out of > the box. I thought something smelled a bit fishy. I meant to annotate the patch with "It is possible I have a broader polkit config issue", but forgot before sending it last night. And indeed after looking again today with fresh eyes I see the problem is in our polkit-default-privs package -> downstream bug. Ignore this patch. Regards, Jim
On Tue, Dec 1, 2020 at 4:23 PM Jim Fehlig <jfehlig@suse.com> wrote: > > On 12/1/20 2:17 AM, Daniel P. Berrangé wrote: > > On Mon, Nov 30, 2020 at 05:28:16PM -0700, Jim Fehlig wrote: > >> As a normal user, 'virsh connect qemu:///system' and > >> 'virsh connect --readonly qemu:///system' will prompt for root password. > >> If the user is added to the libvirt group, only > >> 'virsh connect --readonly qemu:///system' will prompt for root password. > > > > This doesn't make sense - the readonly case should never prompt for > > a password, since libvirtd.polkit.in grants that permission out of > > the box. > > I thought something smelled a bit fishy. I meant to annotate the patch with "It > is possible I have a broader polkit config issue", but forgot before sending it > last night. > > And indeed after looking again today with fresh eyes I see the problem is in our > polkit-default-privs package -> downstream bug. Ignore this patch. > Hah, and I didn't catch this because I rip out the default openSUSE stuff that ruins usability by restricting polkit too much. :) Shame on me for not double checking my environment. :) -- 真実はいつも一つ!/ Always, there's only one truth!
On 12/1/20 5:15 PM, Neal Gompa wrote: > On Tue, Dec 1, 2020 at 4:23 PM Jim Fehlig <jfehlig@suse.com> wrote: >> >> On 12/1/20 2:17 AM, Daniel P. Berrangé wrote: >>> On Mon, Nov 30, 2020 at 05:28:16PM -0700, Jim Fehlig wrote: >>>> As a normal user, 'virsh connect qemu:///system' and >>>> 'virsh connect --readonly qemu:///system' will prompt for root password. >>>> If the user is added to the libvirt group, only >>>> 'virsh connect --readonly qemu:///system' will prompt for root password. >>> >>> This doesn't make sense - the readonly case should never prompt for >>> a password, since libvirtd.polkit.in grants that permission out of >>> the box. >> >> I thought something smelled a bit fishy. I meant to annotate the patch with "It >> is possible I have a broader polkit config issue", but forgot before sending it >> last night. >> >> And indeed after looking again today with fresh eyes I see the problem is in our >> polkit-default-privs package -> downstream bug. Ignore this patch. >> > > Hah, and I didn't catch this because I rip out the default openSUSE > stuff that ruins usability by restricting polkit too much. :) It has been a long time, but I've tripped over default-privs in the past. This time it was the difference between "restricted" (default in SLES) and "standard" (default in openSUSE) rules that got me. See /etc/sysconfig/security. Regards, Jim
On Tue, Dec 01, 2020 at 09:17:01AM +0000, Daniel P. Berrangé wrote: > On Mon, Nov 30, 2020 at 05:28:16PM -0700, Jim Fehlig wrote: > > As a normal user, 'virsh connect qemu:///system' and > > 'virsh connect --readonly qemu:///system' will prompt for root password. > > If the user is added to the libvirt group, only > > 'virsh connect --readonly qemu:///system' will prompt for root password. > > This doesn't make sense - the readonly case should never prompt for > a password, since libvirtd.polkit.in grants that permission out of > the box. The libvirtd.rules file should just be extending what is > defined in the main libvirtd.polkit file. In fact, this caught my eye and it works as expected on Fedora, can you share a bit more on what setup this fails for you? Erik
On Mon, Nov 30, 2020 at 7:29 PM Jim Fehlig <jfehlig@suse.com> wrote:
>
> As a normal user, 'virsh connect qemu:///system' and
> 'virsh connect --readonly qemu:///system' will prompt for root password.
> If the user is added to the libvirt group, only
> 'virsh connect --readonly qemu:///system' will prompt for root password.
>
> The libvirt polkit rules already allow libvirt group members access to
> the rw socket. Add a rule allowing to access the ro socket.
>
> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
> ---
> src/remote/libvirtd.rules | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/remote/libvirtd.rules b/src/remote/libvirtd.rules
> index 01a15fac2e..d9be94fcc4 100644
> --- a/src/remote/libvirtd.rules
> +++ b/src/remote/libvirtd.rules
> @@ -1,5 +1,12 @@
> -// Allow any user in the 'libvirt' group to connect to system libvirtd
> -// without entering a password.
> +// Allow any user in the 'libvirt' group to connect to the system libvirtd
> +// ro and rw sockets without entering a password.
> +
> +polkit.addRule(function(action, subject) {
> + if (action.id == "org.libvirt.unix.monitor" &&
> + subject.isInGroup("libvirt")) {
> + return polkit.Result.YES;
> + }
> +});
>
> polkit.addRule(function(action, subject) {
> if (action.id == "org.libvirt.unix.manage" &&
> --
> 2.29.2
>
>
LGTM.
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
--
真実はいつも一つ!/ Always, there's only one truth!
© 2016 - 2026 Red Hat, Inc.