undismissable, unclickable authentication dialog left on screen (top-left corner) after policykit authentication [pushModal: invocation of begin_modal failed]

Restarting polkit.service does not cause the window to disappear.

Screenshot of the dialog in question. The text comes from aptdaemon's policykit policy.

journalctl output for the period in question, taken from 'journalctl -l --since today | grep gnome-shell'.

13:19 is my restart of the polkit service.

The actual authentication did not succeed, aptdaemon did not start and no packages were installed; so I don't know exactly when this window broke - though I think it was after 13:00, and thus much later than the polkit messages at the beginning of the log. (I certainly didn't have a broken window on my screen for ~2h before filing this bug.)

Apr 15 11:33:29 virgil gnome-shell[4571]: polkitAuthenticationAgent: Received 3 identities that can be used for authentication. Only considering one.
Apr 15 11:33:29 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed
Apr 15 11:33:29 virgil gnome-shell[4571]: polkitAuthenticationAgent: Failed to show modal dialog. Dismissing authentication request for action-id org.debian.apt.install-or-remove-packages cookie 2-c14dea1098d77930282650c2c7031008-3-811320afb0a7974406f93ce80f7d4594
Apr 15 11:59:56 virgil gnome-shell[4571]: remove_mnemonics: assertion 'label != NULL' failed
Apr 15 11:59:56 virgil gnome-shell[4571]: remove_mnemonics: assertion 'label != NULL' failed
Apr 15 12:20:28 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed
Apr 15 12:20:28 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed
Apr 15 12:22:57 virgil gnome-shell[4571]: remove_mnemonics: assertion 'label != NULL' failed
Apr 15 12:22:57 virgil gnome-shell[4571]: remove_mnemonics: assertion 'label != NULL' failed
Apr 15 12:33:28 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed
Apr 15 12:33:28 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed
Apr 15 12:53:18 virgil gnome-shell[4571]: JS WARNING: [resource:///org/gnome/gjs/modules/signals.js 128]: Too many arguments to method Clutter.Actor.destroy: expected 0, got 1
Apr 15 12:56:06 virgil dbus-daemon[1964]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.317' (uid=1000 pid=4571 comm="/usr/bin/gnome-shell " label="unconfined")
Apr 15 12:56:12 virgil dbus-daemon[4403]: [session uid=1000 pid=4403] Activating service name='org.gnome.Nautilus' requested by ':1.26' (uid=1000 pid=4571 comm="/usr/bin/gnome-shell " label="unconfined")
Apr 15 12:56:12 virgil dbus-daemon[4403]: [session uid=1000 pid=4403] Activating service name='org.freedesktop.FileManager1' requested by ':1.26' (uid=1000 pid=4571 comm="/usr/bin/gnome-shell " label="unconfined")
Apr 15 12:56:13 virgil gnome-shell[4571]: [AppIndicatorSupport-DEBUG] Registering StatusNotifierItem :1.80/org/ayatana/NotificationItem/software_update_available
Apr 15 12:56:13 virgil gnome-shell[4571]: [AppIndicatorSupport-FATAL] unable to update overlay icon
Apr 15 12:56:13 virgil gnome-shell[4571]: [AppIndicatorSupport-FATAL] unable to update overlay icon
Apr 15 12:56:13 virgil gnome-shell[4571]: Error connecting to Nautilus
Apr 15 12:56:14 virgil gnome-shell[4571]: Couldn’t parse steam.desktop as a desktop file, will treat it as a regular file.
Apr 15 13:00:08 virgil gnome-shell[4571]: JS WARNING: [resource:///org/gnome/shell/ui/workspacesView.js 639]:...

the window did go away when I did a kill -HUP gnome-shell.

This sounds particularly relevant:

Apr 15 12:20:28 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed
Apr 15 12:20:28 virgil gnome-shell[4571]: pushModal: invocation of begin_modal failed

which seems to be from gnome-shell/js/ui/main.js

It also sounds like this might be the new form of bug 1734095.

Status changed to 'Confirmed' because the bug affects multiple users.

I saw the authentication window only once after resume from suspend to RAM.

But I do get the error messages and my syslog is filled up

Tagging as rls-dd-notfixing, it doesn't prevent the bug to be worked on/fixed but it's not easy enough to trigger/doesn't have enough impacted users or reports to quality as a rls bug atm

Same problem here. I restarted (successfully) apache2 service a few hours ago, then I moved away from my computer, and when I came back, there was this little buggy window (and it's not the first time this bug happens to me)

And when I press ALT+F2, then type "r" and press enter, it's gone !

Why haven't I thought it?! Thank you!

Att,
Charles Fonseca

On Fri, Dec 6, 2019, 09:30 Paul <email address hidden> wrote:

> And when I press ALT+F2, then type "r" and press enter, it's gone !
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1825771).
> https://bugs.launchpad.net/bugs/1824874
>
> Title:
> undismissable, unclickable authentication dialog left on screen (top-
> left corner) after policykit authentication [pushModal: invocation of
> begin_modal failed]
>
> Status in gnome-shell package in Ubuntu:
> Confirmed
>
> Bug description:
> In disco, when policykit prompted me for a password in order for
> update-manager to dispatch instructions to aptdaemon to perform
> package updates, the password dialog remained on the screen after I
> clicked 'authenticate'.
>
> The window is not clickable, it appears not to even be a window -
> mouse presses are received by the window underneath. The exception is
> that the 'cancel' button is active and receives mouse events - but
> clicking it does nothing.
>
> This may be a gnome-shell issue rather than policykit.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 19.04
> Package: policykit-1 0.105-25
> ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1
> Uname: Linux 5.0.0-8-generic x86_64
> NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
> ApportVersion: 2.20.10-0ubuntu27
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Mon Apr 15 13:14:33 2019
> InstallationDate: Installed on 2010-09-24 (3125 days ago)
> InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64
> (20100816.1)
> SourcePackage: policykit-1
> UpgradeStatus: Upgraded to disco on 2019-04-11 (3 days ago)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1824874/+subscriptions
>

I get this all the time after resuming from sleep, unfortunately with wayland it's not possible to reload gnome-shell so I have to log out/in to get rid of it.

Thank you for reporting this bug to Ubuntu.
Ubuntu 19.04 (disco) reached end-of-life on January 23, 2020.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

I've seen this same bug three times in the past two days on a new (up-to-date) ubuntu 19.10 system. The bug is NOT therefore unique to 19.04. Clicking anywhere on the dialog does in fact produce the behavior that would be appropriate for clicking whatever is below the dialog. This appears therefore to be an incorrect painting problem in gnome shell. Restarting gnome-shell (<alt><F2> enter r) does in fact get rid of the incorrectly painted dialog.

Bruce,

We're happy to reopen this bug but can you reconfirm it's exactly the same as the screenshot in comment #3?

Yes Daniel, it is the same as shown in the screenshot in comment #3.

This morning, I managed to trigger this bug again. I installed a new component from the Activities/Search view. The component installed without requiring any authentication, but 30 minutes later, the offending authentication dialog image appeared on the screen.

I believe there are probably two different bugs here:

1. In the ubuntu software install, there is probably a thread synchronization defect that allows software to install without authentication.

2. Separately gnome shell appears to paint widgets even though there is apparently no logic/process attached to the widget.

Just want to add five cents: I am not active user of Ubuntu right now but I faced with the same issue in many other versions of GNOME in other distributions (currently I suffer from this issue in Arch Linux). I suspect that it caused by custom PAM modules which add to authorization process some delays (in my case this module is pam_yubico which waits for user action) but I still do not have a chance to check it.

Sergey, I think you might be onto something. I use a yubikey and have PAM configured to detect the yubikey automatically for sudo. So it could be a timing issue as you suggest, or maybe GNOME is making inappropriate assumptions about whether authentication requires actual user input.

Last night I encountered similar bug behavior with a different message. Several hours after a printing related crash, another orphaned authentication dialog was painted on top of the gnome shell with the message:

Please enter your password to access problem reports of system programs

In light of this related problem and Sergey's suggestion of PAM involvement, I now believe the original bug in this thread is caused by incorrect handling of PAM by gnome shell. There could also be threading problems, insofar as the incorrect painting of an orphaned dialog window seems to occur long after the action that is referenced in the dialog window.

I just tried some experiments with pam_yubico in my distro.

Case 1 (OK):

- Run `systemctl restart some-service` (for example: `systemctl restart libvirtd`).
- Go sleep or lock screen (press Super+L).
- Wakeup and login again.

==> There are no any popups.

Case 2 (Bug):

- Connect Yubikey.
- Edit /etc/pam.d configuration files (for example: common-session in Ubuntu or system-auth in other distro) and describe a long-running `auth sufficient ...` module (for example: pam_yubico.so).
- Run `systemctl restart some-service` (for example: `systemctl restart libvirtd`), interact with the Yubikey.
- Go sleep or lock screen (press Super+L).
- Wakeup and login again.

==> An undismissable popup says that authentication is required to restart libvirtd (or any other service).

I might be experiencing same/similar bug on a fresh install of 20.04. I don't have a Yubikey. Or at least I don't think I do :).

In my case the bug is triggered when I try to open a folder needing root permissions. Sometimes I get an auth dialog and it let's me browse the folder. More often I just get a spinning wheel and nothing happens... or so I think, until I lock my computer. Upon unlocking it, I get a stuck auth window, which is not entirely unlike the one OP is getting (see screen shot attached).

There is no way to get rid of the window, other than reload gnome-shell. (Thanks polalbert!)

@Dimitry, could you give an example of folder triggering a such prompt?

Like Dimitry, I have experienced the same (or a similar) bug on a fresh 20.04 install. I'm attaching a picture of it. Both "Authenticate" and "Cancel" buttons are clickable ("Authenticate" only once) but don't make the window vanish. I confirm that killing the gnome-shell caused the window to disappear.

I also just experienced this same bug on fresh install of Focal 20.04. I don't have Yubikey. Since the appearance of the window is delayed from whatever triggers it, I don't know what the cause is. The behavior is as other describes, a orphaned window on top left corner of screen, clicking the window results in whatever is underneath being clicked. Logging out and relogging makes the window disappear.

Same here with a fresh Ubuntu 20.04 LTS on a laptop (Lenovo Y50). Pressing Alt+F2, typing "r", and pressing enter helps as noted before when this appear.
The only thing related to elevated privileges I can think of is using admin:/// in nautilus.
The problem generally appears after coming back from suspended to resumed state.

Hello,

I've the same issue and actually after coming back.
I saw:
/etc/init.d/gdm3 status
● gdm.service - GNOME Display Manager
     Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: enabled)
     Active: active (running) since Sat 2020-05-02 16:06:55 CEST; 6h ago
   Main PID: 1301 (gdm3)
      Tasks: 3 (limit: 14159)
     Memory: 6.2M
     CGroup: /system.slice/gdm.service
             └─1301 /usr/sbin/gdm3

mai 02 16:06:55 grosPCi7 systemd[1]: Starting GNOME Display Manager...
mai 02 16:06:55 grosPCi7 systemd[1]: Started GNOME Display Manager.
mai 02 16:06:55 grosPCi7 gdm-autologin][1387]: gkr-pam: no password is available for user
mai 02 16:06:55 grosPCi7 gdm-autologin][1387]: pam_unix(gdm-autologin:session): session opened for user default by (uid=0)
mai 02 16:06:56 grosPCi7 gdm-autologin][1387]: gkr-pam: gnome-keyring-daemon started properly

I have configurated ubuntu for an automatic login session.

I will try to set a mandatory password at the logon and coming back..

Hello,

with the same command and after a logout/login, I don't have the same /etc/init.d/gdm3 status
I don't have issue but if I check the status :
kr-pam: unable to locate daem…ile

I didn't see this undimissable screen anymore

regards

oups undismissable

I've been getting exactly the same issue as described here, always when I log in and find an "Authentication Required" dialog window in the top left of the screen. I've attached a screen shot, the details of my environment are below:

OS: PopOS (Ubuntu 20.04 LTS x86_64)
Kernel: 5.4.0-7626-generic
DE: Gnome
Window manager: Mutter

I also have a Yubikey that I'm using in challenge-response mode and have the following line inserted in the following PAM modules:

`auth sufficient pam_yubico.so mode=challenge-response chalresp_path=/var/yubico`

I am having the same problem. A few days ago I upgraded my computer from Ubuntu 19.10 to 20.04. Normally I was starting the MySql server manually. It started working automatically with the update.
When I put the computer to sleep mode and turn it back on, the authentication window for the MySql server is opening at the upper left corner and is not closing in any way.
The thing that catches my attention here is that when I click on the window that does not close, the application under the window detects the click. However, the cancel button and the password text box is not performing their functions even though they sense the clicks correctly.
Notice: Restarting the shell closes the window.

This screenshot is an example of controlling programs which are behind the faulty dialog.

The bug is also present in 20.04. I got it after a system resume from sleep.

I have also been affected by this bug on 20.04

Those adding comments stating you also have the issue could you describe how you trigger it?

I know this is Ubuntu bug reporting tool, but I have the same problem on Fedora. I didn't find this bug reported on Fedora (I'll report it), but I'd like to add some observations for you, so maybe someone will be able to solve this annoying issue.
I use Yubikey to login to my Gnome desktop. Everything works fine until I run any program as root (e.g. virt-manager, disks). Then I'm asked to touch my Yubikey to authorize and to run the program as root. So far good.
But then I lock the screen (or it locks itself after 5 minutes). When I unlock the screen by touching the Yubikey I see the annoyuing dialog with message "System policy prevents management of the local virtualized systems".
I've checked /etc/pam.d/polkit-1 if it uses Yubikey for authentication

#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session include system-auth

and /etc/pam.d/system-auth contains

auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_fprintd.so
auth sufficient pam_u2f.so debug=1
auth sufficient pam_yubico.so id=1 debug=1
...

Login and other PAM modules use system-auth config as well. So I'd expect that polkit should work with this. But it doesn't. Maybe it need more configuration in other pam sections (account, password, session). I'm not PAM expert.

I hope this will help someone to find a fix.

@~seb128 I noticed it after resuming from lock screen. Ubuntu 20.04, upgraded from 19.10

@~seb128 After resuming from the lock screen. Ubuntu 20.04, upgraded from 19.10.

BTW, Alt-F2 "r" doesn't help me because after that all windows become blurry and I have to reboot the computer, which is clearly unacceptable.

Same issue, brand new fresh install of Ubuntu 20.04

For me, sometimes after login login overlay is not disappeared and prevent from showing any window, but mouse and maybe keyboard events still delivered to some screen areas (see screenshoot).

I do not have any hardware keys, such as yubikey

Fortunately, Alt+F2, "r" helps me.

Same problem here after the 20.04 update.
The dialog appears after wake from suspend state, and looks like the screenshot in #3.
Alt+F2, "r" makes the dialog disappear.

I don't have a Yubikey.
Anything else to check, config files, log files ?

Encountered this problem two times in 20.04 LTS. Both times were after I moved away from my computer to go eat, and came back to see this bug.

Tried "Alt+F2" and typed "r", dialog disappeared.

+1

On a fresh 20.04 LTS machine. Saw the dialog after waking up from suspend. Exact same behavior as described earlier.
Alt+F2 followed by 'r' did the trick.

thank you, people - restarting (Alt-F2 > r) indeed gets rid of the window.
Do we know what causes it?
How to fix?

Ubuntu 20.04 running Gnome-Vanilla desktop with nvidia-driver
is this related to snap by any chance? Or to the new disk that I added to my system recently?

can I provide any logs?

cheers

It would be a problem in gnome-shell's dialog code so someone please report it to the gnome-shell developers at:

  https://gitlab.gnome.org/GNOME/gnome-shell/issues

and then tell us the new issue ID.

ID = #3026

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3026

Same problem here, just happened this morning.
---------------------------------------------------------------------------------------------------
vartan@system76:~$ ps axu | grep gvfsd
gdm 4984 0.0 0.0 248336 7500 ? Ssl Aug20 0:00 /usr/libexec/gvfsd
gdm 5002 0.0 0.0 312800 6360 ? Sl Aug20 0:00 /usr/libexec/gvfsd-fuse /run/user/125/gvfs -f -o big_writes
vartan 6798 0.0 0.0 248440 7748 ? Ssl Aug20 0:00 /usr/libexec/gvfsd
vartan 6803 0.0 0.0 378336 6504 ? Sl Aug20 0:00 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
vartan 7182 0.0 0.0 322844 8520 ? Sl Aug20 0:00 /usr/libexec/gvfsd-trash --spawner :1.3 /org/gtk/gvfs/exec_spaw/0
vartan 7337 0.0 0.0 171368 6764 ? Ssl Aug20 0:00 /usr/libexec/gvfsd-metadata
vartan 242879 0.0 0.0 396620 8880 ? Sl Aug21 0:00 /usr/libexec/gvfsd-network --spawner :1.3 /org/gtk/gvfs/exec_spaw/2
vartan 242922 0.0 0.0 323604 8360 ? Sl Aug21 0:00 /usr/libexec/gvfsd-dnssd --spawner :1.3 /org/gtk/gvfs/exec_spaw/4
vartan 330214 0.0 0.0 17664 2500 pts/1 S+ 09:46 0:00 grep --color=auto gvfsd
---------------------------------------------------------------------------------------------------
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
---------------------------------------------------------------------------------------------------
Linux system76 5.4.0-7642-generic #46~1597422484~20.04~e78f762~dev-Ubuntu SMP Wed Aug 19 14:32:27 x86_64 x86_64 x86_64 GNU/Linux
---------------------------------------------------------------------------------------------------
GNOME Shell 3.36.4

I encountered this issue on latest Fedora 32. So this is not unique to ubuntu. I have a dual booted system and when I tried to access windows partition data from fedora, I was required to type the password in authentication dialogue, after which I could access windows data. Then when I locked and unlocked again, this unclickable authentication dialogue box was stuck on top-left corner of the screen (If I tried to click it, whatever was 'behind' it was clicked).

Pressing Alt + F2 and then 'f' removed it.

This happend to when, I set the system to update, and then left it unattended and system got suspended, when I wake it up again the dialog was there unclickable, non cancelable.

seeing more people encountering this - thought I'd share my observations:
- did not see this for a few weeks now
- toyed around with nextcloud for a bit yesterday (the new desktop sync client)
- also tried to connect a (hacked) amazon fire hd10 tablet (which failed, also tried to get connection using gMTP, then left my system to sleep/idle)
- came back to the invisible/unclickable thingie
- alt-f2 + r gets rid of it as usual

last journalctl says:
(especially the last three entries seem interesting)

Sep 04 11:09:45 hostname gvfsd[54716]: A connection to the bus can't be made
Sep 04 11:09:45 hostname gvfsd[56942]: A connection to the bus can't be made
Sep 04 11:09:45 hostname gvfsd[56925]: A connection to the bus can't be made
Sep 04 11:09:45 hostname gvfsd[1976]: A connection to the bus can't be made
Sep 06 12:00:03 hostname gvfsd[120538]: Device 0 (VID=18d1 and PID=0281) is UNKNOWN in libmtp v1.1.17.
Sep 06 12:00:03 hostname gvfsd[120538]: Please report this VID/PID and the device model to the libmtp development team
Sep 06 12:00:03 hostname gvfsd[120538]: Error 1: Get Storage information failed.
Sep 06 12:00:06 hostname gvfsd[120538]: PTP: reading event an error 0x05 occurred
Sep 06 12:00:07 hostname gvfsd[120538]: Android device detected, assigning default bug flags
Sep 06 15:08:14 hostname dbus-daemon[1189]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service' requested by ':1.552' (uid=1000 pid=42440 comm="/usr/libexec/gvfsd-dnssd --spawner :1.3 /org/gtk/g" label="unconfined")
Sep 06 15:08:15 hostname gvfsd[1927]: A connection to the bus can't be made
Sep 06 15:08:15 hostname gvfsd[5385]: A connection to the bus can't be made
Sep 06 15:08:15 hostname gvfsd[8198]: A connection to the bus can't be made
Sep 06 15:08:15 hostname gvfsd[40339]: A connection to the bus can't be made
Sep 06 15:08:15 hostname gvfsd[42440]: A connection to the bus can't be made
Sep 06 15:08:15 hostname gvfsd[8448]: A connection to the bus can't be made
Sep 06 15:08:15 hostname gvfsd[50589]: A connection to the bus can't be made
Sep 06 15:17:00 hostname polkitd(authority=local)[1215]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.gtk.vfs.file-operations-helper for unix-process:7445:35881 [/bin/sh -c pkexec /usr/libexec/gvfsd-admin "$@" --address $DBUS_SESSION_BUS_ADDRESS gvfsd-admin --spawner :1.3 /org/gtk/gvfs/exec_spaw/2] (owned by unix-user:username)
Sep 06 15:17:00 hostname pkexec[7446]: username: Error executing command as another user: Request dismissed [USER=root] [TTY=unknown] [CWD=/home/username] [COMMAND=/usr/libexec/gvfsd-admin --spawner :1.3 /org/gtk/gvfs/exec_spaw/2 --address unix:path=/run/user/1000/bus]
Sep 06 15:17:00 hostname gvfsd[7446]: Error executing command as another user: Request dismissed
username@hostname:~$ ^C

+1 from me

Same dialog as #3

Set to update, went to make a cup of tea, came back to the locked screen.

Entered system password to login, then saw the dialog which wouldn't go away.

Like above, Alt + F2 then entering r fixed it

Ubuntu 20.04.1 LTS

GNOME Shell 3.36.3

Same as the rest got this after returning. But wanted to add one thing nobody did comment about is that I could keep *show/hide my password*! That's a security issue if you do not know yet you can use alt+f2 + r to get rid of the window.

Ubuntu 20.04.1 LTS
GNOME Shell 3.36.3

Same here. Cannot kill it with xkill, but doing de Alt+f2 then press r does the trick.

I'm on Ubuntu 20.04.1 LTS

Problem still present. Just experienced it on Ubuntu 20.04.1 LTS. The provieded workaround to get it removed fixed it.. for now.

Same for me. Also Alt + F2 and executing "r" resolved it...

Can also confirm on Ubuntu 20.04.1 LTS. Didn't find the process so I couldn't kill this annoying window. It popped when I started to install dependancies within pycharm.

Alt+F2 + "r" worked for me. Thanks!

+1, bug still there in 20.04.1 LTS.

Bug exists in 20.10 too, I just triggered it. It happened after screen lock/unlock cycle.

Like other restart got rid of it.

I solved the problem with
$ sudo killall -9 gnome-shell

I'm also experiencing this bug, after a screen lock / unlock cycle.

The "Alt+F2 r" workaround dismisses it, thanks.

(Freshly installed Ubuntu 20.04.1 here.)

20.04.01 right after install, essentially nothing else on the machine

Just happened to me for the first time, on 20.04, "Alt+F2" then entering "r" worked for me, thanks to all who suggested it

Also seeing this on 20.10. Same workaround works.

Those having the issue could you try to describe the actions you did before it happened?

So, the problem only happens to me when the computer locks the screen / suspends. Upon logging in the authentication window appears, being impossible to interact and sometimes causing system crashes. It seems to me that it is some authentication because of the wifi network ...

Same issue here, it is the second time.
Ubuntu 20.04
Just wake up, and my laptop was locked the entire night, I unlocked it, and see the dialog. No other actions.

Alt+F2 and "r", removed the dialog.

Same here, 20.04 installed on a reformatted disk. Nine months without this problem (which had pestered me on 19.10), and now it suddenly pops up - literally. Any progress?

Moved to upstream bug https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3701 which also has a fix proposed in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1662

Just got this for the first time, 20.10. The cancel button reacts to click but does not dismiss. Looks shady so I'm not going to try my password. xkill has no effect. I see it's been nearly two years now.

damn it. folks, i clicked on the status by mistake and changed it to released. I am SO SORRY. Can someone please change it back to Fix submitted?
Again, sorry.

This bug was fixed in the package gnome-shell - 3.38.3-3ubuntu1

---------------
gnome-shell (3.38.3-3ubuntu1) hirsute; urgency=medium

  * debian/patches: Switch to the new API to get actor from inputdevice
    (LP: #1690719)
  * debian/control: Bump dependency on mutter with input thread support
  * debian/patches: Update to MetaCursorTracker API change
  * debian/patches: Do not forward device IDs
  * debian/ubuntu-session-mods/ubuntu.json: Use desktop-icons-ng extension by
    default (LP: #1916511)

gnome-shell (3.38.3-3) unstable; urgency=medium

  * Team upload
  * d/patches: Update to 3.38.3-9-gbdf31febe from gnome-3-38 branch
    - Use image-data in preference to app icon for notifications
    - Don't let fullscreen apps block the workspace-changing animation
    - Don't leave a non-interactable polkit prompt if authentication
      succeeds without requiring user interaction (LP: #1824874)
    - Fix a crash in the blur effect when taking a screenshot or
      screencast
    - Fix a crash involving apps' fallback icons

 -- Marco Trevisan (Treviño) <email address hidden> Fri, 26 Feb 2021 00:51:19 +0100

Just got this yet again. Looked it up before and waited because I saw progress. Glad to see restarting WM wasn't the accepted "fix". Really does come off as a shady auth prompt that end users shouldn't be faced with.

just got this on ubuntu 20.04

It is happening in 20.04 after an update earlier in the week for me.

The same on ubuntu 20.04

Another user affected on 20.04. Happened to me after resuming from sleep. Alt+F2: R made it go away for me as well.

Another user affected on 20.04. here, I don't know how or why, but doing the Alt+F2 r made it go away too.

20.04, POC with VMware® Workstation 16 Pro Version 16.1.0 build-17198959.

To reproduce this issue, follow this steps;
1. Run a vm (preferred which has a DE).
2. Attach your mouse to it by interacting with the vm.
3. Try to open "Virtual Network Editor" which is under "Edit" tab.
( "Authentication Required" window nor the editor wont be appear.)
4. Lock your OS.
5. Unlock your OS.
6. There is the "undismissable, unclickable authentication dialog left on screen (top-left corner)".

How do I figure out which application tripped the policy and then resulted in the dialog?

In my case the unclickable dialog happens on my Desktop PC booting into my Ubuntu 20.04.
No VM, no remote connection, no xRPD involved, no new software installed, no torrents, and downloaded nothing.

I have several virtual networks created by docker, but this setup worked for years until a few days ago.

The only change was that I added a new SSD to the system on top of existing ones, formatted to ext4, but it's not even in fstab yet.

```
apt list gnome-shell -a
Listing... Done
gnome-shell/focal-updates,now 3.36.9-0ubuntu0.20.04.1 amd64 [installed]
gnome-shell/focal-security 3.36.4-1ubuntu1~20.04.2 amd64
gnome-shell/focal 3.36.1-5ubuntu1 amd64
```

Another user affected on 20.04.
Would be nice to have a patch for Ubuntu 20.04 with Gnome Shell 3.36

Disappointing that this bug is still there in
20.04.3 LTS
Gnome v. 3.36.8

The patch looks trivial:

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1662/diffs

But before we can propose it for 20.04 we need a test case written out that anyone can follow. I've tried following some test cases mentioned above but none seem to reproduce the bug for me.

Can anyone provide a new test case?

I have a reproducible test case, but you need to set up for VNC (I have a fresh 20.04 install, running headless, and this bug is a total PITA - it's pretty much permanent. Note that it's worse than the screenshot from comment #3 because the password is also viewable, and anyone can come along, click the eye icon, and see my password). If you don't want to vnc, see below.

In my case, I've installed the tigervnc server (tigervnc-standalone-server). Two changes to /etc/vnc.conf and you're good to go (note that no custom xstartup is required):

# must do this to connect remotely
$localhost = "no";

# set to whatever your remote screen size is
$geometry = "3840x2160";

polkit has issues with remote access and pops up lots of 'Authentication Required' windows. Eventually one will go in the top left corner and stay there, with the described behaviour. I think, but I'm not sure, that one way to trigger this is by hitting RET after entering your password, rather than the Authenticate button. Note that you may have to wait 10 or 15 minutes for another popup if the initial popups don't trigger this bug.

I've added a local polkit policy to try to get rid of the popups, to try to make a remote session look like a local session, which would hopefully get rid of the popups, but this isn't yet working. The Alt F2/r fix described above doesn't work.

If you don't want to run remotely over vnc, you should be able to trigger this by changing the default polkit policy for an app you use. See /usr/share/polkit-1/actions. A good one would be org.freedesktop.color.policy, which is the one which traditionally causes VNC problems ("create a color profile", etc). Find the 'allow active' lines, and replace the 'yes' with something like auth_admin/auth_admin_keep/auth_self_keep/etc. You'll then get the auth popups when you log in, and various time afterwards.

@vanvugt could you or somebody else please back-port that small patch to 20.04 (Gnome Shell 3.36)? Upstream is not going to do it.

I can help to test a proposed package, since I can reliably reproduce it (every time on resume after suspend).

Thank you.

@nanu The blocker for this being uploaded to Ubuntu 20.04 LTS is that we need a step-by-step test case to reproduce the bug and verify the fix.

https://wiki.ubuntu.com/StableReleaseUpdates#Procedure