Comment 4 for bug 1296276

Launchpad Bug Tracker <email address hidden> writes:

> So what is happening is that on the initial login, I get a valid ticket
> cache, owned by my logging-in user, and showing my UID in the file name.
> This ticket works fine. However, once I lock the screen and then unlock
> it, I get a ticket cache owned by root, with "_pam_" in the filename,
> and of course I can't use it because I am not logged in as root.

The _pam_ ticket cache is created during the authenticate step of the PAM
interaction, and is then written to the user's actual ticket cache during
either setcred or open_session. (setcred is the appropriate thing for a
screen saver to call.) It's deleted on pam_end.

This sounds like a screen saver that isn't using PAM properly. It looks
like it's starting a PAM interaction and then only calling authenticate,
never calling setcred, and never ending the PAM interaction, so it leaks a
root-owned ticket cache and never renews your cache.

There used to be widespread problems of this sort due to the number of
people writing screen savers who didn't really understand how PAM worked,
but I thought most of them had been fixed.

You can confirm that it's a problem with this program rather than with
your system configuration by running xscreensaver, locking the screen,
unlocking with your Kerberos password, and seeing if that properly
refreshes your credentials. I know that xscreensaver does PAM properly.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>