GNOME Bugzilla – Bug 701516
GDM crash while abusing lock functionality
Last modified: 2013-06-03 19:33:11 UTC
Abusing lock functionality will crash the gdm service, system cannot recover Steps : 1. Boot System 2. Log in as a user 3. lock the computer 4. While the background window that you have to pull up is active, pull it 2/3 up but don't release the left mouse button 5. Observe you can type the password, type it and then pull down 1/3 of the screen (still left click is pressed all this period) 6. Type enter while pressing the left click button and and the window is 2/3 down 7. After login go to User - lock 8. Observe the GDM theme crash. Other way to reproduce it : 1. Boot System 2. Go to Applications - Terminal 3. Lock the computer 4. Select Login as a different user 5. Login as the same user 6. Lock the computer Expected outcome Computer behaves Actual outcome GDM theme crashes.
Ray and I spent some time analysing this. It turns out to be a combination of two things: 1) The screenshield code does not properly maintain its own state if the presence status changes to idle while the lock screen is deactivating. The underlying reason is that this._isActive is only reset when the deactivation is complete, so this code in onStatusChanged: if (!this._becomeModal()) { // We could not become modal, so we can't activate the // screenshield. The user is probably very upset at this // point, but any application using global grabs is broken // Just tell him to stop using this app // // XXX: another option is to kick the user into the gdm login // screen, where we're not affected by grabs Main.notifyError(_("Unable to lock"), _("Lock was blocked by an application")); return; } if (this._lightbox.actor.visible || this._isActive) { // We're either shown and active, or in the process of // showing. // The latter is a very unlikely condition (it requires // idle-delay < 20), but in any case we have nothing // to do at this point: either isActive is true, or // it will soon be. // isActive can also be true if the lightbox is hidden, // in case the shield is down and the user hasn't unlocked yet return; } ends up first pushing a modal, and then taking the early exit. 2) when doing the unlockSession followed by a switch vt of the second scenario, we are seeing a spurious presence status change to 'idle' To fix 1), the most proper fix would be to queue presence changes and only act on them when we are in a quiescent state (ie not activating or deactivating). The fix for 2) probably involves diving into X input and sync code, and vt switch handling (ugh).
*** This bug has been marked as a duplicate of bug 700839 ***