Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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
Embargoed:

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.