Debugging screen locking problems (Security)

Registered by Marc Deslauriers on 2009-11-09

There is a large quantity of screen locking bugs with many causes, and they are not getting fixed. (See the list on: https://wiki.ubuntu.com/SecurityTeam/Roadmap)

This blueprint is to create a "DebuggingScreenLocking" wiki page, and get the current and new bugs to a triaged state where they can start getting fixed.

Blueprint information

Status:
Complete
Approver:
Robbie Williamson
Priority:
Essential
Drafter:
Marc Deslauriers
Direction:
Approved
Assignee:
Marc Deslauriers
Definition:
Approved
Series goal:
Accepted for lucid
Implementation:
Implemented
Milestone target:
None
Started by
Kees Cook on 2009-11-26
Completed by
Marc Deslauriers on 2010-03-05

Related branches

Sprints

Whiteboard

Work items:
create screen-locking PPA: DONE
create debugging flowchart: DONE
debug screen-locking issues with hamster-applet: DONE
release hamster-applet update: DONE
debug screen-locking issues with totem: DONE
release gnome-screensaver update for totem issue: DONE
debug screen-locking issues with gnome-screensaver activation: DONE
release gnome-screensaver update for activation: DONE
create new apport hooks for gnome-screensaver: DONE
backport apport hooks to older releases in screen-locking PPA: POSTPONED
create wiki page: DONE
describe how screensaver/screen-locking works in wiki page: DONE
add further debugging tips to wiki page: DONE
add known issues to wiki page: DONE
add link to wiki page to all screen locking bugs: DONE
review old bugs for the common Karmic failure (suspend-before-locked): POSTPONED

Gobby notes:
= DebuggingScreensaverFailures =

 * Which window manager are you using?
  * Metacity/Gnome
   * gnome-power-manager
    * configuration for locking in various modes
     * Hibernate
     * Suspend
     * Idleness
    * Default lock behaviors (gconf:apps/gnome-power-manager/lock)
     * lid-close, key event, g-p-m, g-ss lock, g-p-m waits for g-ss reply, devkit-power suspend
      * what happens if g-ss fails or does not reply?
     * there is a bug prior to Karmic where waiting for the lock did not happen
     * Karmic also uses "throttle" vs lock
     * "follow screen saver locking setting in gnome-screensaver for suspend/hibernate" setting
     * if hal is dead, no screen locking seems to happen at all?
    * xsession-errors?
     * enable debug mode?
   * gnome-screensaver
    * idle failure (ie, didn't lock)
     * context menu is open
     * VM window has stolen context?
     * gnome-kerying dialog
     * did some other window say it is the most important via the X protocol?
    * is it running?
    * did it respawn? (got lost on dbus)
    * Is a hack is configured?
     * it is the responsibility of the hack to cover the screen.
     * try blanking the screen instead of using a hack and see if it helps
     * gconf key for hack/blank/random?
     * xsession-errors?
   * User-switcher
    * indicator-session, g-ss lock, g-ss wait, ck new-session (gdm in lucid)
     * what happens on g-ss failure?
     * needs to log errors
  * Compiz/Gnome
   * driver redraws desktop before screensaver layer
  * KDE
  * Xfce

(?)

Work Items