Bug 167479 - xscreensaver can't close cleanly via 3rd party application
Summary: xscreensaver can't close cleanly via 3rd party application
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xscreensaver
Version: 4
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On: 147479
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-03 00:14 UTC by Dimitris
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-03 17:39:39 UTC
Type: ---
Embargoed:


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

Description Dimitris 2005-09-03 00:14:02 UTC
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-03 00:15:42 UTC
Created attachment 118414 [details]
Patch to add the -wslunlock option in xscreensaver-command

Comment 2 Dimitris 2005-09-03 00:19:29 UTC
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-03 01:39:39 UTC
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 17:39:39 UTC
Hi Dimitris,

We aren't likely to commit this type of patch without upstream buy-in.

Comment 5 Dimitris 2005-09-08 13:31:50 UTC
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.