Bug 196151

I have checked that this is only when using a kerberos login and not a ldap.

if you get rid of setuid of kcheckpass, it should work again.

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

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.

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.

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:

#%PAM-1.0
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.

Changing only /usr/bin/kcheckpass to 0755 works for me. Is there a reason why it
was changed to suid recently? 

the suid is needed if you use ldap, but causes problem if someone uses krb :(

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..

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 
use_authtok
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.

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.

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?

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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

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.

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. 

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?

(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?

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.

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?

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.