Red Hat Bugzilla – Bug 66902
separate PAM configuration for kscreensaver is not used
Last modified: 2007-11-30 17:06:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020509
Description of problem:
kcheckpass uses /etc/pam.d/kde when unlocking the screen. It should rather use
/etc/pam.d/kscreensaver. The mechanism appears to be:
kdesktop -> setenv(KDE_PAM_ACTION, KSCREENSAVER_PAM_SERVICE)
kcheckpass -> use /etc/pam.d/"caller"( = getenv(KDE_PAM_ACTION))
KSCREENSAVER_PAM_SERVICE is a macro from configure and will be set to pam_action
which is set itself by --with-pam=XXXX.
This is funny as the same spec file creates a separate /etc/pam.d/kscreensaver
(which will apparently not be used).
The RedHat spec file uses --with-pam=kde. Net result is that kscreensaver uses
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.mess up /etc/pam.d/kscreensaver, deny everybody and put in fancy
2.lock your screen in KDE
Actual Results: unlock works
Expected Results: You should stay locked out since PAM should not be able to
authenticate you using the "kscreensaver" service. It can, because it uses the
"kde" service instead.
BTW, this is not our actual problem, we are rather stuck with pam_afs and AFS
token extension on unlock. But the above should demonstrate this well enough.
In the spec file you could use --with-kss-pam=kscreensaver which should do the
It works for me. it's intended to use kde pam file instead separate file.
The problem comes from having expiring credentials, like AFS tokens or Kerberos
TGTs. You normally don't want to create a new session (voiding all existing
credentials) if you go for a 5-minute break. If you split between "session
start" (like logging into gdm/kdm) and "session continuation", you can do things
like non-destructive token renewal. Please consider re-opening, the changes for
Red Hat should be minimal.
ok, i will add separate pam config file for kscreensaver in next comming RHEL5.
Many Thanks for your report.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'RHEL 3.9'
Ticket type set to: 'Problem'
This event sent from IssueTracker by navid