Bug 178002

*** This bug has been marked as a duplicate of bug 177450 ***

So problem in bug 177450 is that kcheckpass must be suid root, so in my instalation I have

-rwsr-xr-x 1 root users 45414 Янв  1 23:40 kcheckpass

but I can`t unlock the screen! So I reopen bug.
I use recent svn trunk

ok, this might sound stupid ... but sometimes it is necessary to make it *not* setuid root. can you try it? :}

try running kcheckpass on the command line and see what it says.

examine the authpriv.* syslog facility for messages from PAM.

Yes I have tried both variants. when kcheckpass not setuid it doesn`t work from command line, when it`s setuid it works prefectly from command line. 

wait, do you have russian (or other non-ascii) characters in the password?

No only ascii, and only latin symbols (no special symbols or digits)

that might indicate that you have configured the use of different pam services for different things, but the service definition for the screen saver does not actually exist. check like that: while the unlock dialog is up, switch to a text console and run "ps ax|grep '[k]checkpass'" (note that you have to be fast, as the dialog goes away) to find the actual kcheckpass call. try running that command on the command line. the -s parameter names the service definition that should be found in /etc/pam.d/. if there is none, make install as root in workspace/krunner/lock should fix it, otherwise you'll have more "fun".

Yes I have a great fun! kcheckpass works prefectly well, but it ... doesn`t called when unlock dialog work! NO [k]checkpass process during I enter password in dialog appears. I know about it because I use such script in console:

#!/bin/sh

echo > result.txt

while [ -f work ]
do
        ps aux | grep checkpass >> result.txt
done

echo FINISH!

which work during I`m tying to unlock the screen. Native 4.1.3 KDE thats distributed with OpenSUSE 11.1 works prefectly. But Compiled from sources in home directory, works as I describes. Have you got any idea about it? 

ahh, suse. I had the same problem: making it suid root isn't enough on suse. I never solved the problem, though :( maybe you can drag a suse person over here and ask them what extra security they've got that's getting in the way?

once we find a solution we should put it on techbase for the benefit of other suse users.

SSJ_GZ suggests changing it from root.users to root.root - does that help any?


btw, it was using kcheckpass in my case - I symlinked it to /bin/true and then I could unlock the screen with anything :) defeats the purpose of locking, though, unless your only concern is cats walking on the keyboard.

Hi,

I had exactly the same problem on suse 11.1 with my own built trunk version (suse packages work OK). So I had a look at how the kcheckpass from packages is configured. It indeed has the suid bit and must be owned by root. I also noticed the group was set to 'nogroup' (dont know if this is the missing part for people still having the problem).

so I did:
chown root:nogroup kcheckpass 
chmod u+s kcheckpass

and the unlocking works now! =)

Same here:
KDE 4.3 RC3 from openSUSE (11.1) on Thinkpad
I even don't get a dialog to enter the password or swipe a finger.
The only dialog is: 
Session locked by XXX 
Authentication failed
All three buttons are greyed out.

This is annoying, especially on notebooks, where screen locking is often used

Is this still happening?

(In reply to comment #13)
> Is this still happening?

Yes this is still happening. I built KDE 4.6.80 from KDE trunk, on Fedora 14. I am not being able to unlock even after i did

sudo chown root kcheckpass
sudo chmod u+s kcheckpass

Though it worked when i installed kcheckpass with sudo make install, giving it the right permissions.

distro configuration issue