Version: (using KDE KDE 3.5.2) Installed from: Compiled From Sources OS: Linux Hi, we are just switching to kerberos and are experiencing some bugs/problems with several software components. One of them is the kde screensaver - it doesn't renew kerberos tickets. E.g. if one logs in via kdm one gets a kerberos ticket which will expires after a couple of hours. Over night, when the desktop was locked, kscreensaver should also renew this ticket. Unfortunately it doesn't. Looking through the sources, the problem is in kcheckpass (kcheckpass/checkpass_pam.c A debian bugreport for xlockmore describes the problem and solution. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344600 kdm/backend/client.c also calls pam_acct_mgmt() and pam_setcred(). However is does not call pam_authenticate(). The manpage of pam_acct_mgmt() suggests pam_acct_mgmt() call after pam_authenticate(), so in principle those calls only need to be added. I'm only not sure what to do if an error is returned back - should it be ignored, since pam_authenticate() works, or should one test for errors? Thanks, Bernd
to sum it up, are you suggesting that kcheckpass must call pam_acct_mgmt() first to make pam_setcred() succeed?
Sorry, my analysis was completely wrong, I even didn't notive there is already a pam_setcred() call. To get it working I had to change the flag to pam_setcred(): - pam_error = pam_setcred(pamh, PAM_ESTABLISH_CRED); + pam_error = pam_setcred(pamh, PAM_REINITIALIZE_CRED); pam_acct_mgmt() is not required.
ah, fine. we already had PAM_REFRESH_CRED, now we have PAM_ESTABLISH_CRED (because of the friggin' krb5 module, iirc.), so i guess it's about time to try PAM_REINITIALIZE_CRED - the suse dudes suggested to do it anyway.
There seem to be several pam_krb5 modules out there - every linux distribution uses its own, bsd has its own, etc. And all of them have their own bugs... and probably also use different flags ;)Though we are using debian in the institut we switched to fedoras module for several reasons. I'm just comparing both codes and it seems both are checking for PAM_REINITIALIZE_CRED | PAM_REFRESH_CRED. The debian module even has code for PAM_ESTABLISH_CRED (only that refreshing doesn't seem to work at all). So next time when someone sends a bug report like this, you should ask which pam module is used ;) Cheers, Bernd
I'd like to confirm that we get expected behaviour (credentials refreshed instead of new (and unused) credentials) with either PAM_REINITIALIZE_CRED or PAM_REFRESH_CRED in #2, when running with Red Hat pam_krb5-2.2.8 (FC5), kde-3.3.1 (RHEL4). Most PAM modules seem to treat these two as synonyms, but as per http://docs.sun.com/app/docs/doc/816-4863/6mb20lvfk?a=view I would prefer PAM_REFRESH_CRED under these circumstances: [..] If the session is the renewal of an existing session, such as for lockscreen, pam_setcred() with the PAM_REFRESH_CRED flag should be called. If the session is changing the credentials, such as using su or assuming a role, then pam_setcred() with the PAM_REINITIALIZE_CRED flag should be called [..] (also the OpenGroup pam_setcred() documentation has PAM_REINITIALISE_CRED To reinitialize user credentials. PAM_REFRESH_CRED To extend the lifetime of the user credentials. which would be roughly in line with SUN's documentation).
can we do something about this ? its once again time for a new suse release and this issue is still not fixed. also (yet another) novell bugreport about kcheckpass: https://bugzilla.novell.com/show_bug.cgi?id=203570
i'm fine with changing it back to PAM_REFRESH_CRED - after all, it's The Right Thing To Do (TM). i'm not sure about the suid issue, though. we could simply drop privs, but some modules might not like it. the alternative would be setting the ruid to the euid, effectively creating the situation found on logon time. however, i have no idea whether all relevant modules are expected to be prepared for this.
> ------- Additional Comments From ossi kde org 2006-11-07 20:07 ------- > i'm fine with changing it back to PAM_REFRESH_CRED - after all, it's The > Right Thing To Do (TM). i'm not sure about the suid issue, though. we could > simply drop privs, but some modules might not like it. the alternative > would be setting the ruid to the euid, effectively creating the situation > found on logon time. however, i have no idea whether all relevant modules > are expected to be prepared for this. Don't know if its interesting, but from the novel bugreport I see, that suid is set by default, isn't it? On debian (sarge and sid) kcheckpass doesn't have suid/suid flags set. Since it doesn't have those flags for a rather long time, I guess there are also no serious problems related to it. Bernd
SVN commit 603230 by mueller: use PAM_REFRESH_CREDENTIALS instead of REINITIALISE_CRED CCBUG: 127012 M +2 -8 checkpass_pam.c --- trunk/KDE/kdebase/workspace/kcheckpass/checkpass_pam.c #603229:603230 @@ -187,14 +187,8 @@ return AuthBad; } - /* Refresh credentials (Needed e.g. for AFS (timing out Kerberos tokens)) */ - /* REINIT_CRED and REFRESH_CRED are not clearly defined and thus likely to - * fail, so we use ESTABLISH_CRED ... */ - pam_error = pam_setcred(pamh, PAM_ESTABLISH_CRED); - if (pam_error != PAM_SUCCESS) { - pam_end(pamh, pam_error); - return AuthError; - } + pam_error = pam_setcred(pamh, PAM_REFRESH_CRED); + /* ignore errors on refresh credentials. If this did not work we use the old once. */ pam_end(pamh, PAM_SUCCESS); return AuthOk;
SVN commit 603231 by mueller: use PAM_REFRESH_CRED instead of PAM_REINITIALIZE_CRED CCBUG: 127012 M +2 -8 checkpass_pam.c --- branches/KDE/3.5/kdebase/kcheckpass/checkpass_pam.c #603230:603231 @@ -187,14 +187,8 @@ return AuthBad; } - /* Refresh credentials (Needed e.g. for AFS (timing out Kerberos tokens)) */ - /* REINIT_CRED and REFRESH_CRED are not clearly defined and thus likely to - * fail, so we use ESTABLISH_CRED ... */ - pam_error = pam_setcred(pamh, PAM_ESTABLISH_CRED); - if (pam_error != PAM_SUCCESS) { - pam_end(pamh, pam_error); - return AuthError; - } + pam_error = pam_setcred(pamh, PAM_REFRESH_CRED); + /* ignore errors on refresh credentials. If this did not work we use the old once. */ pam_end(pamh, PAM_SUCCESS); return AuthOk;
*** Bug has been marked as fixed ***.
*** Bug 78677 has been marked as a duplicate of this bug. ***
I've been looking at old KDE bugs in Gentoo and came across this one. I just checked my system and noticed that kcheckpass for both KDE-3.5.10 and KDE-4.2.1 are still SUID and the latter is also SGID. If it has been deemed as not required, is there any reason to keep installing them as such?