Bug 167479 - xscreensaver can't close cleanly via 3rd party application
xscreensaver can't close cleanly via 3rd party application
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xscreensaver (Show other bugs)
4
All Linux
medium Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On: 147479
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-02 20:14 EDT by Dimitris
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-03 13:39:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to add the -wslunlock option in xscreensaver-command (23.00 KB, patch)
2005-09-02 20:15 EDT, Dimitris
no flags Details | Diff

  None (edit)
Description Dimitris 2005-09-02 20:14:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
Xscreensaver doesn't provide a simple interface for 3rd party applications in order to make it unlock. Its possible from another application to tell xscreensaver to lock (xscreensaver-command -lock), but unlocking isn't possible authentication is required.

Unfortunately, this can be a problem if someone is using a security device which does all the authentication.

One such example is the Wireless Security Lock (http://www.thinkgeek.com/gadgets/security/698d/ and http://www.sitecom.com/products_info.php?product_id=293&grp_id=1).

A clean and simple method to solve this problem, is to add an option like "xscreensaver-command -wslunlock" which cleanly unlocks the display even is a password is required (assumes the Wireless Security Lock has done that already).

A patch is supplied (written by Brian Schau, http://www.schau.com/l/wsl/) which adds the proper command to xscreensaver-command.


Version-Release number of selected component (if applicable):
xscreensaver-base-4.21-4

How reproducible:
Always

Steps to Reproduce:
1. make sure xscreensaver is setup to ask for a password
2. enable xscreensaver and let it lock the display
3. try to cleanly close the screensaver without typing a password once other authentication method has been performed.

  

Actual Results:  xscreensaver can't be unlocked.

Expected Results:  idealy, unlock the display.


Additional info:
Comment 1 Dimitris 2005-09-02 20:15:42 EDT
Created attachment 118414 [details]
Patch to add the -wslunlock option in xscreensaver-command
Comment 2 Dimitris 2005-09-02 20:19:29 EDT
I forgot to mention that the supplied patch applies to xscreensaver 4.22. Fedora
Core 4 comes with version 4.21, hopefuly it won't be incompatible.
Comment 3 Jamie Zawinski 2005-09-02 21:39:39 EDT
As I said when Brian mailed me about this, this patch is no good.  Adding domain-specific knowledge 
about this particular device to xscreensaver not a general solution.

The right way to solve this problem is to write a PAM module that knows about your security dongle.  It 
would go like this:

 - xscreensaver is running
 - user jiggles mouse
 - xscreensaver asks PAM, "shall we unlock the screen?"
 - PAM says "yes (because the dongle is in range)"
Comment 4 Ray Strode [halfline] 2005-09-03 13:39:39 EDT
Hi Dimitris,

We aren't likely to commit this type of patch without upstream buy-in.
Comment 5 Dimitris 2005-09-08 09:31:50 EDT
Thank you all for taking the time to look at this patch.

Note You need to log in before you can comment on or make changes to this bug.