Karmic screensaver asks for password

[Xandros Pilosa]

Dne 13.11.2009 (pet) ob 10:07 -0800 je NoOp zapisal(a):
> On 11/13/2009 07:43 AM, Laura Conrad wrote:
> ...
> > 
> > I really think the xscreensaver thing is a red herring.  When I first
> > reported the problem, it was an xscreensaver dialog box, and a
> > subsidiary problem was that the xscreensaver configuration tool no
> > longer had the box for checking whether you wanted to lock the
> > screen.  Of course, if the system has hard-wired the answer, it's
> > better to not have the box.
> > 
> > But since I removed xscreensaver, the box is a gnome-screensaver box,
> > and the bug is that the lock screen entry in the gnome-screensaver
> > configuration box isn't having any effect.  I did a "ps auxww" from a
> > terminal while it was on screen this morning and my guess is that the
> > program that's asking me for my password is "gnome-screensaver-dialog
> > --enable-switch".
> > 
> 
> You might have a look through:
> https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver
> and this one is interesting:
> https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/411350
> [gnome-screensaver not functioning]
> and consider filing a bug report. But first I'd try testing to see if
> it's actually the screensaver or something else:
> 
> $ mv /home/<username>/.gconf/apps/gnome-screensaver
> /home/<username>/.gconf/apps/x-gnome-screensaver-x
> $ sudo apt-get purge gnome-screensaver
> $ sudo apt-get update
> $ sudo apt-get upgrade
> $ sudo apt-get install gnome-screensaver
> 
> Note: yes I've just done this on a karmic machine to test before
> suggesting :-)
> 
> .gconf/apps/gnome-screensaver is your screen saver settings and is an
> xml file which can be looked at/edited in the standard gedit text
> editor. When you reinstall gnome-screensaver it will create a new
> .gconf/apps/gnome-screensaver, so you can compare against the old
> 'x-gnome-screensaver-x' file. I doubt this is the issue, but it can't
> hurt to give it a try in the event the xml file is corrupted. Also note,
> that you can/should move 'x-gnome-screensaver-x' out of that folder
> eventually, as the gconf editor will pick it up as an app. Won't hurt
> anything to leave it there, but may be confusing later on if you forget
> what it is.
> 
> You can also try the 'gnome-screensaver-command' options, see:
> <http://manpages.ubuntu.com/manpages/karmic/en/man1/gnome-screensaver-command.1.html>
> 
> Try inhibiting it first, then deactivate & then exit.
> 
> Note that I'm guessing at all of this right now... :-)
> 
> 

And when you done with above procedure and if there is no result I would suggest just two more things to try.
Namely this is what puzzles me:
You (Laura) wrote as an answer to my question

> Xandros> So, if I understand you correctly, when you the machine
>     Xandros> is idle (with lid opened) for some time, the screen goes
>     Xandros> blank and when it resumes, you are not asked for
>     Xandros> password?
> 
> Yes.

According to this, maybe gnome-screensaver is not yet mature for
conviction, at least not just itself.

Furthermore, screen lock is activated by closing / opening the lid.
You (Laura) wrote:
> 
>     >> >> The "Settings" => "Power Management" screen is set to "Blank
> Screen"
>     >> >> when the lid is closed.
> 
>     Xandros> Can you verify this with gconf-editor ?
>     Xandros> /apps/gnome-power-manager/buttons/lid_ac and
>     Xandros> /apps/gnome-power-manager/buttons/lid_battery
>     Xandros> value should be "blank" in both cases.
> 
> Yes.
> 

1. experiment would be to set
/apps/gnome-power-manager/buttons/lid_ac
to the value "nothing"

2. experiment would be to set 
/apps/gnome-power-manager/lock/suspend
to "false"

In both cases be sure that both
apps/gnome-screensaver|lock_enabled
and
/apps/gnome-power-manager/lock/blank_screen
 keys have false values - are blank

Note, that I wrote experiment, as I am kicking in the dark here (but you
already may noticed this).
Please remember to revert settings (keys) to their original values, if
changes don't work.
If the second case shows desired result (no lock), you may have to think
about security issues, as the session won't be locked at resuming from
suspend.
In both cases, this is not real solution, even if it works for you and
you should report a bug, as NoOp suggested, but in this case against
gnome-power-manager, I assume.

Regards