GNOME Bugzilla – Bug 693145
Race with gnome-keyring while starting up gnome-shell
Last modified: 2021-07-05 14:45:25 UTC
When starting up gnome-shell and registering the prompter that gnome-keyring-daemon uses, there is a race condition where a o.g.k.SystemPrompter is auto-started by the bus, but then gnome-shell comes and kills it and replaces it. It seems that in this situation gnome-keyring-daemon could wait for a response and hang.
Created attachment 235149 [details] [review] Patch to try Some work arounds, but not sure if this should be the entire final solution.
Jimmac does this solve the problem for you? You could apply the patch directly to /usr/share/gnome-shell if you like, and then restore the package after.
Attachment 235149 [details] does not solve the problem for me.
Further information may be obtained from the attachments in [1] on the Fedora Tracker. [1] https://bugzilla.redhat.com/show_bug.cgi?id=907156
It turns out that this is not directly related to the hang in the RHBZ bug above, and the hangs. The effect of this bug is to show a non-shell window when prompting for an unlock right after starting the machine.
Wrt. Attachment 235149 [details] : Applying this patch to gnome-shell again after the subject of [1] was successfully fixed by an update to GCR 3.7.2 did not help the problem with gnome-keyring-daemon spawing a native window rather than a shell-popup.
It may be noted that when previously replaced as described in [1] with $ gnome-keyring-daemon --replace (where the popup would fail to appear on auto-login), the popup would then suddenly appear, but it would be the same gray popup and not the gnome-shell one.
As discussed on IRC, the core of the issue as identified in comment 5 is that requests for authentication, proxied by gnome-keyring-daemon/gcr to the prompter's name on the bus, by applications which inquire for secrets come in *before* gnome-shell claimed that name. DBus therefore runs the service-file association, i.e. the GtkPrompter the window of which does not integrate well. By nature, this can only solved by a lock somewhere in the process, effectively locking the call to the prompter by gnome-keyring/gcr to after gnome-shell has successfully claimed the name on the bus. Two solutions have been proposed: 1) Lock in gnome-session, only spawning subsequent children after gnome-shell has successfully claimed the name 2) Lock in gcr, waiting for the name being claimed before calling to it (and thereby triggering the service-file association) I hereby propose a third solution, based upon the second combining the benefits from 1 and 2, evading the disadvantages, which are 1*) Realistically, gnome-shell is "just another process" and not specifically designated by anything making it more special than, say, gnome-online-accounts. In this sense, it appears unreasonable to have everything else wait for gnome-shell. Such a lock could severaly slow down the appearance of the desktop. 2*) The problem here is that we'd have to inform gnome-keyring/GCR of that it's meant to wait for gnome-shell to claim the name (which is not apparent, considering gnome-keyring may run in an enviroment without gnome-shell and therefore using the GtkPrompter). Informing it by simply replacing it is out of the question because we'd lose the information that it obtained from PAM. Informing it over the DBus is again subject to asynchronicity - in an extreme case it may only receive that information after it has already received requests for passwords but before gnome-shell has claimed the name on the bus. As pointed out, it is inevitable to introduce a wait for gnome-shell somewhere. In my solution, the lock is in gnome-session, but as opposed to 1, the lock waits for gnome-keyring-daemom to acknowledge that gnome-shell has become the prompter. This solves the problem outlined in 2* and at the same time has the advantage that we are not waiting for a possibly lengthy startup as outline in 1* - instead, gnome-keyring is already running and the average lock-time will only be that required to inform the running keyring over the bus. Also, gnome-keyring may, contrary to gnome-shell, be considered a "special case" (given that it's a PAM, which also limited us in 2*) and it's therefore more reasonable to specifically account for it. In a nutshell: GDB - start -> gnome-session gnome-session informs any running instances of gnome-keyring-daemon of gnome-shell being the prompter and waits for acknowledgement of that message gnome-session performs all outstanding tasts gnome-keyring/gcr does not call for prompts before the prompter's name has been claimed (by gnome-shell)
For the record: As I've mentioned, I'd like to work on a solution that avoids prompting the user for unlock passwords right after login (auto-login or password login). But if you can build a solution to this race that's not too expensive (code or complexity wise) then I'm not against it. In theory something like what you propose could work. But I haven't looked at all the intricacies. Will do that once you've posted patches, and we're not just talking theory. Keep in mind that gnome-keyring daemon is initialized from within the session using a command like 'gnome-keyring-daemon --start'. In theory you could add another argument to this command as the method that gnome-session uses to communicate to gnome-keyring-daemon to wait for the shell prompter. Once again, take a look at: https://live.gnome.org/GnomeKeyring/RunningDaemon FWIW, if you think the start up of gnome-keyring is complex, that's because it is :) I'm looking forward to simplifying that once systemd manages the session.
The same problem can potentially happen with PolicyKit dialogs. And I think it also happens sometimes with notifications, when processes like ABRT try to notify about existing crash files on login: error messages about no daemon being present are printed to the logs. The whole thing really sounds like it would be fixed by systemd handling the session, since it would know in advance the D-Bus names that the Shell claims.
*** Bug 692826 has been marked as a duplicate of this bug. ***
*** Bug 688741 has been marked as a duplicate of this bug. ***
Another mitigating bug fix: bug #695485
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.