Bug 196151 - Kscreensaver fails to unlock
Summary: Kscreensaver fails to unlock
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Ben Levenson
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-06-21 16:10 UTC by Nate Steffan
Modified: 2009-07-14 17:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-14 17:22:44 UTC
Type: ---

Attachments (Terms of Use)
Proposed spec-file patch (372 bytes, patch)
2008-11-09 16:20 UTC, Mary Ellen Foster
no flags Details | Diff

Description Nate Steffan 2006-06-21 16:10:14 UTC
Description of problem:
Upon trying to unlock kscreensaver it returns with this message:

Cannot unlock the session because the authentication system failed to work;
you must kill kdesktop_lock(Process Id) manually

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
We are using pam_krb5 and ldap for pam backends to authenticate.
------- /etc/pam.d/kscreensaver -----
auth       sufficient	pam_timestamp.so
auth       include     system-auth
account    required	pam_nologin.so
account    include     system-auth
password   include     system-auth
session    include	system-auth
session    required    pam_loginuid.so
session    optional	pam_timestamp.so
session    optional    pam_selinux.so
session    optional	pam_console.so

------- /etc/pam.d/kcheckpass -----
auth       sufficient	pam_timestamp.so
auth       include     system-auth
account    required	pam_nologin.so
account    include     system-auth
password   include     system-auth
session    include	system-auth
session    required    pam_loginuid.so
session    optional	pam_timestamp.so
session    optional    pam_selinux.so
session    optional	pam_console.so

------- Relevant /var/log/messages ------
Jun 21 10:45:02 xt23 kcheckpass: pam_krb5[27538]: TGT verified using key for
Jun 21 10:45:02 xt23 kcheckpass: pam_krb5[27538]: authentication succeeds for
'nate' (nate@MATH.UMN.EDU)
Jun 21 10:45:02 xt23 kcheckpass: pam_krb5[27538]: won't refresh credentials
while running setuid/setgid

Comment 1 Nate Steffan 2006-06-21 20:27:56 UTC
I have checked that this is only when using a kerberos login and not a ldap.

Comment 2 Than Ngo 2006-06-22 16:04:12 UTC
if you get rid of setuid of kcheckpass, it should work again.

as a quick workaround yhou should do; chmod 755 /usr/bin/kcheckpass

Comment 3 Nate Steffan 2006-06-22 18:11:21 UTC
kcheckpass and kscreensaver do not have the setuid bit set.

-rw-r--r-- 1 root root 369 Jun 21 11:04 kcheckpass
-rw-r--r-- 1 root root 472 Jun 21 15:56 kscreensaver

I tried changing the permissions to 0755 on both of those files and it is still
not working.

Comment 4 Nate Steffan 2006-06-22 18:28:46 UTC
Sorry I looked at the comment wrong.  But even when /usr/bin/kcheckpass is not
setuid it will not authenticate.  Since it doesn't have the setuid bit set it
cant access the kerberos keytab.

Comment 5 Nate Steffan 2006-06-22 19:54:26 UTC
Ok we found a work around for this.

When /usr/bin/kcheckpass is setuid, pam_krb5 does not like this.
When /usr/bin/kcheckpass is non-setuid, pam_krb5 does not like that it cannot
read the host's keytab file. So the work around is to chmod 0755
/usr/bin/kcheckpass and then edit the kcheckpass pam.d file so it looks like this:

auth       sufficient   pam_timestamp.so
auth       sufficient pam_krb5.so novalidate
auth       include      system-auth
account    required     pam_nologin.so
account    include     system-auth
password   include     system-auth
session    include      system-auth
session    required    pam_loginuid.so
session    optional     pam_timestamp.so
session    optional    pam_selinux.so
session    optional     pam_console.so

The main thing here is the novalidate attached to the pam_krb5 line.  This tells
pam to not check the hosts keytab entry. This is less than ideal, and a fix
should be made to either pam_krb5 or kcheckpass.

Comment 6 Kostas Georgiou 2006-06-23 12:29:38 UTC
Changing only /usr/bin/kcheckpass to 0755 works for me. Is there a reason why it
was changed to suid recently? 

Comment 7 Than Ngo 2006-06-23 12:41:04 UTC
the suid is needed if you use ldap, but causes problem if someone uses krb :(

Comment 8 Kostas Georgiou 2006-06-23 14:25:01 UTC
Aha, bug #189790 I suspect, not that I understand why using pam_ldap requires
root priviliges. 

The weird thing is that everything was working until a couple of days
ago or so and bug #189790 was fixed some time ago. I noticed that for some time
now (couple of weeks, a month maybe) the kdescreensaver stoped updating my
kerberos tickets (easy to spot when you run nfs4 with kerberos) but I didn't had
time to chase it which might be related to this. Do you remember when the suid
bit was added? The breakage happened a couple of days ago so it might be some
other change upsetting everything.

I hope that a similar change is not planned for the upcoming RHEL{3,4} updates
since it's going to cause major problems for us. I'll have to remember to check
the betas I guess..

Comment 9 Andrew Baumann 2006-08-21 00:28:09 UTC
I'm not sure if this is the same bug or not, but it seems to be closely 
related so I'll just add my 2c here.

Since recent updates to FC5 (kdebase-3.5.4-0.2.fc5, and at least one previous 
version), /usr/bin/kcheckpass is not installed SUID root, and I can't unlock 
the screen saver unless I make kcheckpass setuid again.

I am using both pam_unix and pam_ldap, but the account that can't be unlocked 
is located in the local files (/etc/{passwd,shadow}) and so should be checked 
by pam_unix. My /etc/pam.d/system-auth file has:
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass 
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     required      pam_limits.so
session     required      pam_unix.so
session     optional      pam_ldap.so

When I try to unlock and kcheckpass is not setuid, /var/log/secure says:
Aug 21 10:00:47 zarquon kcheckpass: pam_unix(kscreensaver:auth): 
authentication failure; logname=andrewb uid=1046 euid=1046 tty=:0 ruser= 
rhost=  user=andrewb

I also get error messages in /var/log/messages about pam_ldap being unable to 
bind. This is broken, because (from my reading of the auth lines in the pam 
config) it should get as far as pam_unix.so and succeed, and pam_ldap 
shouldn't even be invoked. Confirming this, if I comment out the system-auth 
lines with pam_ldap, the unlocking still fails, so this is not an 
LDAP-specific problem.

I'm guessing that kcheckpass needs to be setuid root to be able to read the 
passwords in /etc/shadow.

Comment 10 Mary Ellen Foster 2007-10-11 10:57:01 UTC
This is, as far as I can tell, still an issue. On my F7 system, I updated to
kdebase-3.5.7-13.1.fc7 yesterday, which removed the setuid bit on
/usr/bin/kcheckpass again, so again I had to chmod u+s to make unlocking work.
Is there something I should configure on my system so this doesn't keep
happening? This computer was "yum update"d from FC6, so there may be some
lingering old configuration.

Comment 11 Mary Ellen Foster 2008-02-25 16:31:10 UTC
Note: this is still a problem. Every time that I update kdebase,
/usr/bin/kcheckpass loses its setuid bit, and every time I need to redo the
chmod u+s before I can use kdesktop_lock. Would it make sense to chmod the file
inside the kdebase rpm?

Comment 12 Bug Zapper 2008-04-04 03:07:44 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 13 Mary Ellen Foster 2008-04-04 07:21:06 UTC
Still an issue in Fedora 8; in fact, it hit me again when I installed
kdebase-3.5.9-7.fc8 on Monday. Sorry, I guess I should have changed the
"release" field earlier.

Comment 14 Mary Ellen Foster 2008-07-17 08:07:00 UTC
Still an issue in Fedora 9, except the thing you need to kill is now
"krunner_lock" instead of "kdesktop_lock". Solution is the same (except for the
path): chmod u+s /usr/libexec/kde4/kcheckpass. 

Comment 15 Mary Ellen Foster 2008-07-29 08:07:19 UTC
Happened again on the most recent Fedora 9 KDE update. Is there some reason not
to add the chmod u+s to the kdebase-workspace rpm?

Comment 16 Mary Ellen Foster 2008-11-07 09:40:30 UTC
(Broken record ...) Just happened again with kdebase-workspace-4.1.2-10.fc9.i386. Is there anything that would actually be broken if we did "chmod u+s /usr/libexec/kde4/kcheckpass" inside kdebase-workspace?

Comment 17 Mary Ellen Foster 2008-11-09 16:20:21 UTC
Created attachment 323016 [details]
Proposed spec-file patch

Here's a proposed patch adding the setuid bit to the kcheckpass executable. It seemed to work fine when I built it just now.

Comment 18 Mary Ellen Foster 2009-01-30 12:23:33 UTC
Oddly, this remains an issue on my work desktop machine -- which was originally installed with Fedora $whatever-was-current in January 2006 and upgraded ever since -- but is not an issue on my laptop or netbook, both of which have fresh Fedora 10 installs. What's the difference?

Comment 19 Bug Zapper 2009-06-09 22:10:59 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 20 Bug Zapper 2009-07-14 17:22:44 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.