Cannot unlock the session if the session is locked by screensaver or locked from start menu, KDE 3.5.6

Bug #92932 reported by erzhong
8
Affects Status Importance Assigned to Milestone
kdebase-workspace (Ubuntu)
Fix Released
Critical
Harald Sitter

Bug Description

After upgrade to KDE 3.5.6, if the session is locked manually from kde menu or locked by screensaver, I cannot unlock it. The unlock dialog appears when I touch the mouse or keyboard, but when I type the password, nothing appears in the dialog box (there should be a '*' for every character in password when I type ). However, I can use Ctrl+Alt+1 to go to virtual terminal, or use Ctrl+Alt+Backspace to restart the session to login again.

I am using Kubuntu 6.10 on a IBM T42.

Revision history for this message
Marco Maini (maini10) wrote :

Thanks for this report. It's a very strange behaviour. When you type password, does KDE display any error (such as incorrect passwords)?
Is this problem present since you have installed Kubuntu or it is appear next? Thanks again.

Changed in kdebase:
assignee: nobody → maini10
status: Unconfirmed → Needs Info
Revision history for this message
erzhong (gnulinuxfun) wrote :

It does not display anything when I type. After I typed in the password, and click on unlock, it displays 'unlock failed'.

Revision history for this message
Marco Maini (maini10) wrote :

When you type password, doesn't appear little point instead of '*'?

Revision history for this message
taj (othertaj) wrote :

It did not unlock in my case, either. I could not unlock with my password, but I could only start a second session, that also locked after some time.
I opened a third session from a remote computer to kill kdesktop_lock, but by mistake I killed the lock on the 'wrong' session (i.e., the first one), and when I wanted to switch from the current session (the second, which I should have unlocked, but still was locked), X crashed. I lost a 24 hr calculation with this, so I was not amused.

Revision history for this message
taj (othertaj) wrote :

PS: you do not see any error message, apart from the 'unlock failed' message, you can still start a new session
I could not even go to terminal with ctrl+alt+1, so if I would not have had remote access, I would only be able to move on by killing the x-session

Revision history for this message
Marco Maini (maini10) wrote :

Please try to obtain a backtrace of the crash and post here. See https://wiki.ubuntu.com/DebuggingProgramCrash for detailed information. Thanks again.

Revision history for this message
SimSQ (daniel-ssq89) wrote :

I face the same problem but only under special circumstances.

kdesktop_lock doesn't respond to the keyboard if I

1) Suspend the machine (to disk, that is). If I just lock the screen, I can't reproduce the problem.
2) Resume the machine
3) *** Pressing spacebar *** to activate the password dialog. If I shake the mouse, the dialog works fine.

I suspect taj's problem is different from erzhong's. erzhong's problem sound similar to mine: the keyboard does not work at all. For example, the tab key does not cause focus to shift between controls. However X remains responsive to Ctrl-Alt-1 requests. The program doesn't crash throughout the episode, so it's not possible to get the backtrace... is it?

----
By the way, there's a cleaner way to get back to work>> Ctrl-Alt-1, login, execute

$ killall kdesktop_lock

Revision history for this message
Marco Maini (maini10) wrote :

I agree with you. tai's problem seems X server crash not related with the original report. Please add information about your version of Kubuntu. Thanks.

Revision history for this message
SimSQ (daniel-ssq89) wrote :

Fiesty with KDE 3.5.6. I think I just reproduced it without having to suspend my computer-- still somewhat randomly that is. But it can still only be triggered by keyboard.

Revision history for this message
Marco Maini (maini10) wrote :

This bug seems quite similar to bug 120670 and bug 106579.
Please add these information to help developers with your problem (give these command from shell and attach here the outputs):
     uname -a > uname-a.log
     dmesg > dmesg.log
    sudo lspci -vvnn > lspci-vvnn.log
Thanks again.

Revision history for this message
SimSQ (daniel-ssq89) wrote :

No it's not the same. I can suspend and resume as many times as I like with no problems at all as long as I I activate the password dialog by mouse only. It's definitely not a hardware issue. bug 120670 concerns a _failed_ suspend.

as for bug 106579... I don't know what to make of it. The bug reporter provided very few details. Moreover, this is a software issue. I can kill kdesktop_lock and use KDE with the keyboard and mouse as usual. The SCIM relationship might be worth pursuing -- but I'm not sure if the behaviour of password boxes are supposed to be affected by input methods.

Revision history for this message
Marco Maini (maini10) wrote :

Have you tried disabling Scim? (It is not a solution but we can know if the bug happens the same or not). Thanks.

Revision history for this message
SimSQ (daniel-ssq89) wrote :

Just tried disabling SCIM. I think I can reproduce it with much better certainty than the kate bug.

Steps to reproduce (working one)
1) command 1:
$ XMODIFIERS= kdesktop_lock --forcelock

2) Wait 10-20 seconds. --> doesn't work if I don't wait
3) Press spacebar.
4) Type your password (it works!)

5) in the shell: $ XMODIFIERS=@im=SCIM kdesktop_lock --forcelock
6) Repeat (3), (4)
7) Type password (fails)
8) Try to <Tab> to shift focus to the Cancel button (fails)
9) Go to another terminal and kill kdesktop_lock.
10) Ponder.

Revision history for this message
Marco Maini (maini10) wrote :

Despite of your detailed procedure, I'm still unable to reproduce it. I leave this bug unassigned, so I hope that someone could confirm it. Thanks.

Changed in scim:
assignee: maini10 → nobody
Revision history for this message
erzhong (gnulinuxfun) wrote : Re: [Bug 92932] Re: Cannot unlock the session if the session is locked by screensaver or locked from start menu, KDE 3.5.6
Download full text (3.5 KiB)

I installed Kubuntu 7.04 and used new instruction on scim/skim website to
turn on skim using im-switch. The problem is gone.

The original problem might be associated with a config file
/etc/X11/Xsession.d/75custom-scim_init
which I added following some old instructions to turn on skim/scim. I
deleted this file and use the im-switch to turn on skim/scim, and the
problem is solved.

The old config file probably contains:
export XMODIFIERS="@im=SCIM"
export GTK_IM_MODULE="scim"
export XIM_PROGRAM="scim -d"

im-switch added a new file, 80im-switch in /etc/X11/Xsession.d/.

These are the scim related packages I installed:
dpkg -l scim*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii scim 1.4.4-7ubuntu1 smart common input method platform
ii scim-anthy 1.2.1-1build1 SCIM IMEngine module for Anthy
un scim-canna <none> (no description available)
un scim-chewing <none> (no description available)
un scim-chinese <none> (no description available)
un scim-config-gc <none> (no description available)
un scim-config-so <none> (no description available)
un scim-frontend- <none> (no description available)
ii scim-gtk2-immo 1.4.4-7ubuntu1 GTK+2 input method module with SCIM as
backe
un scim-hangul <none> (no description available)
un scim-m17n <none> (no description available)
ii scim-modules-s 1.4.4-7ubuntu1 socket modules for SCIM platform
ii scim-pinyin 0.5.91-0ubuntu smart pinyin IM engine for SCIM platform
un scim-prime <none> (no description available)
ii scim-qtimm 0.9.4-0ubuntu5 SCIM context plugin for qt-immodule
un scim-server-so <none> (no description available)
un scim-skk <none> (no description available)
un scim-tables-ad <none> (no description available)
un scim-tables-ja <none> (no description available)
un scim-tables-ko <none> (no description available)
un scim-tables-zh <none> (no description available)
un scim-uim <none> (no description available)

dpkg -l skim*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii skim 1.4.5-1ubuntu1 smart common input method platform for
KDE
ii skim-scim-piny 0.5.91-0ubuntu Skim support for Smart Pinyin IMEngine

I am not sure this problem has anything todo with some of the scim packages
or not.

On Monday 25 June 2007, SimSQ wrote:
> Just tried disabling SCIM. I think I can reproduce it with much better
> certainty than the kate bug.
>
> Steps to reproduce (working one)
> 1) command 1:
> $ XMODIFIERS= kdesktop_lock --forcelock
>
> 2) Wait 10...

Read more...

Revision history for this message
Ming Hua (minghua) wrote :

On Tue, Jun 26, 2007 at 08:43:59PM -0000, erzhong wrote:
> I installed Kubuntu 7.04 and used new instruction on scim/skim website to
> turn on skim using im-switch. The problem is gone.

Thanks for the follow-up.

> The original problem might be associated with a config file
> /etc/X11/Xsession.d/75custom-scim_init
> which I added following some old instructions to turn on skim/scim. I
> deleted this file and use the im-switch to turn on skim/scim, and the
> problem is solved.

I remember reading something like this on wiki.ubuntu.com. Such
outdated and broken documentations should be fixed.

> The old config file probably contains:
> export XMODIFIERS="@im=SCIM"
> export GTK_IM_MODULE="scim"
> export XIM_PROGRAM="scim -d"

The content looks correct, it's more likely the order (75) is the
problem.

> im-switch added a new file, 80im-switch in /etc/X11/Xsession.d/.

Ming
2007.06.28

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for scim (Ubuntu) because there has been no activity for 60 days.]

Revision history for this message
Artur Schmitt (schmitt) wrote :

Hello,

I just upgraded from Kubuntu 7.04 to kubuntu 7.10 and have exactly the same problem on an AMD64 machine, i.e.

> ... if the session is locked manually from kde menu or locked by screensaver,
> I cannot unlock it. The unlock dialog appears when I touch the mouse or keyboard,
> but when I type the password, nothing appears in the dialog box (there should be
> a '*' for every character in password when I type ). However, I can use Ctrl+Alt+1
> to go to virtual terminal, or use Ctrl+Alt+Backspace to restart the session to
> login again.

I also deleted the file

/etc/X11/Xsession.d/75custom-scim_init

Nevertheless, the problem remains.

All the best and thanks for your help

Changed in scim:
status: Invalid → Incomplete
Revision history for this message
Dragomir Minkovski (dejuren) wrote :

I have fresh Kubuntu 7.10 installation, and I have also the problem when unlocking. The most strange thing is, I have no problem with that on a second PC - it just works. The workaround can be found in ubuntuforums.org:
sudo chmod 4755 /usr/bin/kcheckpass

Still it is not clear why it's working on a second PC, the permissions there are 755.

Revision history for this message
z3non (tom-uttenthaler) wrote :

I had this problem in an up-to-date-Kubuntu-8.04 since an kde upgrade as the original poster reported. The 'sudo chmod 4755 /usr/bin/kcheckpass' did solve the problem for me, thx Dragomir.

This should be included in an upgrade script. The bug had nothing to do with scim (in my case). Unlocking now works also while skim or scim is running.

Changed in scim:
status: Incomplete → Confirmed
Revision history for this message
z3non (tom-uttenthaler) wrote :

... and after an upgrade to intrepid, i had the same problem with kde4, wasn't able to unlock, until I did a 'sudo chmod 4755 /usr/lib/kde4/libexec/kcheckpass' - this should probably be fixed before a release ...

Changed in kdebase-workspace:
assignee: nobody → apachelogger
importance: Undecided → Critical
milestone: none → ubuntu-8.10
status: Confirmed → Triaged
Changed in kdebase-workspace:
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package kdebase-workspace - 4:4.1.2-0ubuntu4

---------------
kdebase-workspace (4:4.1.2-0ubuntu4) intrepid; urgency=low

  * Don't remove suid bit from /usr/lib/kde4/libexec/kcheckpass (LP: #92932)

 -- Harald Sitter <email address hidden> Sun, 05 Oct 2008 19:10:09 +0200

Changed in kdebase-workspace:
status: In Progress → Fix Released
Revision history for this message
z3non (tom-uttenthaler) wrote :

I've found out, that the problem lies in the permissions of /etc/shadow, which were wrong in my system for some reason, as I explained it in #279560. So if this gets fixed (I assume in base-passwd), the permissions of kcheckpass can be set the following way:

$ sudo chgrp /usr/lib/kde4/libexec/kcheckpass
$ sudo chmod 2755 /usr/lib/kde4/libexec/kcheckpass

It doesn't need the SUID bit, GUID bit and the appropriate group is enough, when /etc/shadow has the right permissions (owned and readable by group 'shadow')

regards,
tom

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.