Locked password on live CD interferes with screen lock

[Chip Piller]

The latest versions of the live CD now use a locked password. If a user boots
the live CD, does some work on the computer, and then selects "Lock Screen"
from the drop down menu, the screen will lock as expected. However, when the
user returns to the computer and attempts to access the locked ubuntu session
the user is prompted for a password which cannot be supplied.

[Matt Zimmerman (mdz)]

As I mentioned on the mailing list, I think the ideal would be for xscreensaver
to refuse to lock the screen when the user's password is locked, but since it
uses PAM, I don't think this is feasible.

Perhaps the next best thing would be to disable screen locking on the live CD.
This is something which should be discussed on the ubuntu-devel mailing list in
order to open the discussion to a wider audience.

[Chip Piller (piller)]

OK, I'll post to the ubuntu-devel list. However, I don't think the solution
should be to disable screen locking. I think the live CD should be as close as
possible to the install version (actually I think there really should just be
one CD that can be both an install CD and a live CD).

[Matt Zimmerman (mdz)]

*** Bug 14183 has been marked as a duplicate of this bug. ***

[Neal McBurnett (nealmcb)]

This has stung me multiple times already. Some people use ubuntu live for real
tasks,
and being locked out is a big hassle. So I consider this a high-priority bug.

At this point it would help if there were at least some instructions in the
release notes or wherever, telling people the best
ways to work around the problem. It seems that you can switch to a virtual
terminal (ctrl alt F1) and do some things
(e.g. close down file systems and reboot cleanly). Perhaps the process doing
the locking can be killed
or something, so the user can actually get back into the GUI session. I've seen
suggestions that a password can be
set for the ubuntu user, but my last attempt failed if I recall correctly.
Thanks.....

[Sebastien Bacher (seb128)]

*** Bug 16571 has been marked as a duplicate of this bug. ***

[Mikel Ward (mikelward)]

Neal,
All you need to do is change to a virtual terminal and issue "sudo passwd
ubuntu" to set a new known password then return to the X display and enter the
new password to unlock, however a novice user is unlikely to know to do this!

[Matt Zimmerman (mdz)]

casper (0.65) breezy; urgency=low

  * As a performance optimization, only reconfigure gnome-panel-data if
    booting on a laptop
  * Disable the "lock screen" menu item (Ubuntu bug#13497)

 -- Matt Zimmerman <email address hidden> Wed, 8 Jun 2005 16:02:14 -0700

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Does this stop locking the screen when closing a laptop lid, or is the patch
here just disabling the gnome menu item ?

[Matt Zimmerman (mdz)]

This bug is back due to the optimization which skips this script on non-laptops,
and should be fixed again for final

[Matt Zimmerman (mdz)]

Scratch that; the script is smarter than that. There must be some other reason
why it isn't working. Seb, any ideas? This is what it's doing:

panel_version=$(dpkg-query -W --showformat='${Version}' gnome-panel-data
2>/dev/null) || panel_version=""
if [ -n "$panel_version" ]; then
    gconftool-2 -t bool -s /apps/panel/global/disable_lock_screen true
fi

[Matt Zimmerman (mdz)]

Also, a user reported that this is also an issue with the "New Login" feature.
Can we disable the locking there as well, or do we need to find a way to cripple
xscreensaver locking entirely? (Oliver, what are our options for that?)

> New login screen worked okay logged out and was met with a password
> request for the screensaver for user ubuntu.
> What I did next: used a terminal, found the pid of the xscreensaver,
> killed it with -9, went back into session no mouse.
> Ctrl + Alt +Backspace
> Auto login by user ubuntu
> Used that for a bit, tested some more components.

This is a new bug, and might imply that we need a more general solution for
#7150, since there are other parts of the desktop which lock the screen.

[Oliver Grawert (ogra)]

i think something similar to the LTSP_CLIENT patch will do, i'll try to fix it
until final...

[Oliver Grawert (ogra)]

ok, i think i found a quick fix, if its possible to run: export
RUNNING_UNDER_GDM="True" from casper before the session starts, locking will be
disabled... (i'll add a real empty password check later too if still required)

[Colin Watson (cjwatson)]

(In reply to comment #13)
> ok, i think i found a quick fix, if its possible to run: export
> RUNNING_UNDER_GDM="True" from casper before the session starts, locking will be
> disabled... (i'll add a real empty password check later too if still required)

I've done this now, thanks, although it's a pretty ugly solution. If anything
better can be done, please do so.

[Sebastien Bacher (seb128)]

(In reply to comment #10)

> panel_version=$(dpkg-query -W --showformat='${Version}' gnome-panel-data
> 2>/dev/null) || panel_version=""
> if [ -n "$panel_version" ]; then
> gconftool-2 -t bool -s /apps/panel/global/disable_lock_screen true
> fi

This script seems to be right. What is the issue exactly? The gconf key is only
for the panel entry, not for the other locking way there is

[Chip Piller (piller)]

I filed this bug originally, this one continues to cause a lot of people a lot
of grief.
I see in the comments suggestions of a quick fix or ugly solution.

My suggestion:
1) keep it simple, keep breezy-live as close as possible to breezy-install
2) the default user login should have a default password (possibly empty).
3) the default user login and password for breezy-live should be made well known
so as to not cause grief, consider modifying the popup window that asks for the
password to include default user login and password information.
4) breezy-live users should be able to change passwords, create users, install
openssh to allow for remote logins if desired. The user should be able to use
breezy-live in pretty much the same way as breezy-install and this includes the
ability to lock/unlock the screen.

Note: I presently have a lab computer with no hard drive running hoary-live with
an uptime of ~80 days, I have changed passwords, setup remote login with ssh and
can lock/unlock the screen on this machine. I move files around as needed to
other machines on the network, it works fine.

[Matt Zimmerman (mdz)]

(In reply to comment #15)
> (In reply to comment #10)
>
> > panel_version=$(dpkg-query -W --showformat='${Version}' gnome-panel-data
> > 2>/dev/null) || panel_version=""
> > if [ -n "$panel_version" ]; then
> > gconftool-2 -t bool -s /apps/panel/global/disable_lock_screen true
> > fi
>
> This script seems to be right. What is the issue exactly? The gconf key is only
> for the panel entry, not for the other locking way there is
>
>

The problem is that the panel entry is still there.

[Sebastien Bacher (seb128)]

(In reply to comment #17)

> The problem is that the panel entry is still there.

And the gconf key has the correct value during the session? Changing the key
here update the menu just fine ...

[Dennis Kaarsemaker (dennis)]

*** Bug 23143 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

(In reply to comment #18)
> (In reply to comment #17)
>
> > The problem is that the panel entry is still there.
>
> And the gconf key has the correct value during the session? Changing the key
> here update the menu just fine ...

I didn't check that specifically, but I assume it was set, because Lock Screen
doesn't lock the screen.

[sam tygier (samtygier)]

now that the live cd uses gnome-screensaver what is the status of this bug?

[Daga (daga)]

I just booted a slightly modified Kubuntu live-cd (6.06.1 with some added packages). After going to the main menu -> Switch User -> "Ubuntu TTY login (vt1)" then trying to switch back with alt+f7 I was greeted with a locked screen. It didn't accept a blank password and as it was in a VM I couldn't hit ctrl+alt+f1 without my Xorg stealing the keyboard combination. At that point killing the VM was the only option.

I think this bug is still an issue.

[Oliver Grawert (ogra)]

well, its fixed in all used screensaver daemons in ubuntu since they respcet the RUNNING_UNDER_GDM environment variable ... in case that doesnt work in kubuntu, kubuntu needs to implement something similar.

[Yuriy Kozlov (yuriy-kozlov)]

I just ran into this with the Kubuntu Edgy live-cd, 9/5/06 daily build. I let powermanager lock the screen when the laptop lid is closed, then couldn't unlock it because it wanted a password.

[Chip Piller (piller)]

The screen locking behavior still needs work in the latest edgy liveCD, Sept. 5, 2006 build. The problem with the user being able to lock the screen and not be able to unlock the screen has been fixed which is good.

The edgy liveCD user is still presented with options to lock the screen, in the screensaver preferences gui and in the logout screens. None of these options however will actually lock the screen, therefore this is a bug.

If a user of the edgy livecd creates a user account with valid password and attempts to lock the screen, the screen will still not lock.

Finally, not too long ago it was possible to right click on a panel, select "add to panel ...", and add the "lock screen" applet to the panel. This no longer seems to be possible.

[Yuriy Kozlov (yuriy-kozlov)]

The problem is still present on the Kubuntu Feisty Herd 4 CD.

[Chandru (chandru-in-deactivatedaccount)]

I have the problem when using Kubuntu Feisty Fawn Live CD (Final Release).

When I lock the screen while using the Live CD, the screen gets locked. However, I'm unable to unlock the screen. The unlock screen does not accept an empty password for unlocking the screen.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

fix committed for kubuntu

[Sarah Kowalik (hobbsee-deactivatedaccount)]

uploaded. This is too late for tribe 1, so I've milestoned it for tribe 2, to check that it works. And to check out how launchpad auto-changelog-closing works.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

okay, closing by changelog doesn't work. Manually marking as fix released.

[Xavier Brochard (xavier)]

The problem is still present on the Kubuntu Gutsy Beta Live CD

[Sergey Volkov (serg-volkov)]

Here is a workaround for Kubuntu LiveCD screen lock:
Click "Start New Session" in screensaver password dialog, log in with empty password, open terminal (ex. Konsole) and set nonempty password with passwd command.

[Thomas (t.c)]

Hi, please make a fix to this. On a live system from usb stick the file /root/etc/environment grows and grows because nobody check if the line exist there.

better it is like this:

grep RUNNING_UNDER_GDM /root/etc/environment >/dev/null 2>&1 || echo 'RUNNING_UNDER_GDM="yes"' >> /root/etc/environment

Thanks

[Thomas (t.c)]

ok, sorry... wrong bug report :D

can somebody point me to the right way? The bug is in casper initrd.z from livecd/usb-drive in the file /scripts/casper-bottom/10adduser

above the line is this comment:
# XXX - awful hack to stop xscreensaver locking the screen (#7150)

but the bug number point to a complete other bug report?!

[Tormod Volden (tormodvolden)]

Thomas, 7150 was the number for this bug in the old Ubuntu bugzilla (http://bugzilla.ubuntu.com/show_bug.cgi?id=7150) which was migrated to Launchpad with new numbers.