Bug 1568213 - click cancel in gnome-shell polkit dialog, all future polkit connections timeout unless shell is restarted
Summary: click cancel in gnome-shell polkit dialog, all future polkit connections time...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 28
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F28FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-04-17 01:21 UTC by yucef sourani
Modified: 2018-04-25 13:33 UTC (History)
18 users (show)

Fixed In Version: gnome-shell-3.28.1-2.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-25 00:04:25 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab gnome-shell/issues/221 0 None None None 2018-04-24 18:02:17 UTC

Description yucef sourani 2018-04-17 01:21:57 UTC
Description of problem:

1-run virt-manager or gnome-boxes (import from system broker).

2-press on Cancel in polkit window.

3-restart virt-manager or try connect to qemu:///system Connection .

4-polkit window fail to launch.


Error:

Unable to connect to libvirt qemu:///system.

error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1036, in _do_open
    self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open
    open_flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.




Version-Release number of selected component (if applicable):

virt-manager-1.5.1-1.fc28.noarch
virt-manager-common-1.5.1-1.fc28.noarch

gnome-boxes-3.28.2-1.fc28.x86_64


libvirt-daemon-driver-storage-scsi-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-logical-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-core-4.1.0-2.fc28.x86_64
libvirt-glib-1.0.0-5.fc28.x86_64
python2-libvirt-4.1.0-1.fc28.x86_64
libvirt-daemon-driver-storage-4.1.0-2.fc28.x86_64
libvirt-daemon-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-iscsi-4.1.0-2.fc28.x86_64
libvirt-daemon-kvm-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-nodedev-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-qemu-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-sheepdog-4.1.0-2.fc28.x86_64
libvirt-gobject-1.0.0-5.fc28.x86_64
libvirt-bash-completion-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-disk-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-zfs-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-network-4.1.0-2.fc28.x86_64
libvirt-daemon-config-network-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-rbd-4.1.0-2.fc28.x86_64
libvirt-libs-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-nwfilter-4.1.0-2.fc28.x86_64
libvirt-client-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-interface-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-storage-mpath-4.1.0-2.fc28.x86_64
libvirt-daemon-driver-secret-4.1.0-2.fc28.x86_64
libvirt-gconfig-1.0.0-5.fc28.x86_64
libvirt-daemon-driver-storage-gluster-4.1.0-2.fc28.x86_64


polkit-pkla-compat-0.1-12.fc28.x86_64
polkit-libs-0.114-1.fc28.x86_64
polkit-0.114-1.fc28.x86_64


dbus-1.12.0-1.fc28.x86_64

Comment 1 Cole Robinson 2018-04-17 19:21:03 UTC
I tried with virt-manager, seems to work fine for me. I'm using gnome-shell, and my user is an admin so it's only asking for user password, not root.

What desktop env are you using?

Comment 2 yucef sourani 2018-04-17 20:54:23 UTC
(In reply to Cole Robinson from comment #1)
> I tried with virt-manager, seems to work fine for me. I'm using gnome-shell,
> and my user is an admin so it's only asking for user password, not root.
> 
> What desktop env are you using?

gnome shell on wayland (fedora 28 workstation 64bit)

my user is an admin to .

Comment 3 Cole Robinson 2018-04-24 14:31:36 UTC
Okay I managed to reproduce. It's not virt specific. This is with up to date f28, gnome-shell, X session, though user reports wayland as well. User is an admin

Simplify open the control center users panel, click Unlock, polkit dialog pops up asking for user password, click cancel. Click unlock again, nothing happens. Other polkit using apps have the same issue: firewall-config just freezes, system-config-print Unlock doesn't do anything. virsh --connect qemu:///system will hang and eventually report the CheckAuthorization timeout error.

Looks like this is a gnome-shell issue, since alt+f2 'r' will get out of this state. I did try downgrading f28 polkit to the latest 113 version build and it didn't fix the issue.

Reassigning to gnome-shell

Comment 4 Cole Robinson 2018-04-24 14:38:48 UTC
Proposing as a freeze exception since this issue is pretty gnarly and can break a bunch of apps

Comment 5 Adam Williamson 2018-04-24 16:48:39 UTC
To clarify: once it's in the 'broken' state, is it broken for *all* apps? Or is this a per-app thing - if you cancel for virt-manager, future virt-manager dialogs fail, but future dialogs from other apps still work, etc?

Comment 6 Cole Robinson 2018-04-24 17:18:00 UTC
Breaking it in one app breaks it in all apps.

I'm also interested to know if it reproduces this reliably for other people... it didn't trigger for me on my first attempt but today it's happening 100% for me across multiple reboots

Comment 7 Adam Williamson 2018-04-24 17:55:47 UTC
Just tried it on my main desktop (which runs 28), reproduced first time for me.

Comment 8 Adam Williamson 2018-04-24 17:58:08 UTC
I think we should also at least consider this as a blocker, criteria to consider are "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" (as you can get to at least Users and maybe other affected things through the panel) and "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" (configuring the firewall is pretty 'basic functionality' for firewall-config, creating users is 'basic functionality' for Users, etc.)

Comment 9 Adam Williamson 2018-04-24 18:00:59 UTC
<halfline> adamw: we already have a fix for that gnome-shell upstream
<adamw> well, that's good news
<adamw> can someone backport it sharpish? :P
<halfline> sure i can do it right now
<adamw> what's the commit?
<halfline> it's gnome-shell bug
<halfline> one sec
<mcatanzaro> https://gitlab.gnome.org/GNOME/gnome-shell/commit/7c9dbc66d9ab1f3adad29c827fac2d7d3ee05fae.patch
<halfline> yup

Comment 10 Adam Williamson 2018-04-24 18:03:09 UTC
I'm definitely +1 FE for this, having reproduced it and seen the upstream report and fix, which is pretty clear and simple.

Comment 11 Stephen Gallagher 2018-04-24 18:19:28 UTC
+1 blocker

Comment 12 Kevin Fenzi 2018-04-24 19:11:33 UTC
I guess +1 blocker.

Comment 13 Mohan Boddu 2018-04-24 19:15:27 UTC
+1 Blocker

Comment 14 Adam Williamson 2018-04-24 19:17:25 UTC
That's enough votes to accept as blocker at least for now (if we changed our minds we could always re-vote at go/no-go, if the fix somehow doesn't work or causes problems).

Comment 15 Jared Smith 2018-04-24 19:20:17 UTC
+1 blocker, +1 FE

Comment 16 Fedora Update System 2018-04-24 19:22:43 UTC
gnome-shell-3.28.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d7b3e68ad

Comment 17 Fedora Update System 2018-04-25 00:04:25 UTC
gnome-shell-3.28.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 yucef sourani 2018-04-25 13:33:22 UTC
thank you all, the problem was resolved in gnome-shell-3.28.1-2.fc28


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