[Dovecot] Automatically Cleaning Kerberos Credential Cache Files

[Ben Morrow]

At  3PM -0500 on 10/12/12 you (Maura Dailey) wrote:
> I'm in a situation here at work where I'm trying to support a mixed 
> network of OS X and RHEL desktop machines with a Postfix/Dovecot 
> combination.
>    - user account information is stored in LDAP
>    - user credentials are in MIT Kerberos
>    - server is running RHEL 6/Dovecot 2.0.9/Postfix 2.6.6
> 
> I am currently using the PAM passdb module to authenticate my users (I 
> began to have trouble with using GSSAPI directly). After I implemented 
> it, a few weeks later, I noticed that some users were no longer getting 
> their mail if they hadn't logged in during the past day. Postfix's mailq 
> showed that hundreds of messages were backing up in the queue. I 
> eventually tracked it down to leftover Kerberos credential cache files 
> (/tmp/krb5cc_????) sitting in /tmp on the mail server. The presence of 
> expired credential files was preventing Postfix from delivering mail to 
> those users' mail spools. If I delete the credential files manually, 
> Postfix immediately delivers the queued emails.

This is rather odd. Is krb5-authenticated NFS involved here, or does
Postfix's delivery make any other use of Kerberos? The only other thing
I can think of is that so many expired ccaches are accumulating that the
user goes over their inode quota.

> Currently, I have a cron job deleting the files manually every night. 
> Obviously, this is a cruddy solution.

Well, I don't know about that: obviously, it would be a good idea to
work out what's going on here, in case it causes anything else to go
wrong, but a cronjob clearing out /tmp is a good idea in any case.

> I have Dovecot configured on a 
> RHEL 6 box. The Pam stack on a RHEL 6 machine uses sssd (pam_sss.so) for 
> authentication with Kerberos, not pam_krb5.so. I'm trying to track down 
> which piece of the puzzle is responsible for cleaning up leftover 
> credential caches. Is there a configuration option I can pass to 
> Dovecot's passdb directly to clean up these cache files?

There are two relevant Dovecot settings: passing setcred=yes to the pam
passdb will make Dovecot call pam_setcred, and passing session=yes will
make it open and immediately close a PAM session. (Probably it ought to
wait until the IMAP user logs out to close the session, but currently it
can't do that because of the way the passdb lookups are done.) Changing
either of these may have an effect, depending on when exactly your PAM
module creates and destroys ccaches.

> Do others 
> generally have more success using a custom PAM stack with pam_krb5.so 
> instead of pam_sss.so?

Well, I don't use RH (I use FreeBSD), but I use and would recommend Russ
Allbery's pam_krb5.so, which may or may not be the same as the normal
pam_krb5.so provided by your system. It has options to control whether
and where ccaches are created; assuming Dovecot doesn't need krb5 creds
(say, for NFS), you would probably be better off telling it not to
create a permanent ccache at all.

http://www.eyrie.org/~eagle/software/pam-krb5/

> Poring over sssd's configuration options didn't 
> reveal anything useful. I'm still not sure why Postfix even cares if 
> there are expired credential cache files in /tmp at all.
> 
> I'm back to trying GSSAPI directly again as well in the meantime on a 
> few test clients. When I used that in the past, users were getting 
> issued duplicate Kerberos tickets and users were forced to log into the 
> mail server directly using SSH after a day in order to get their mail to 
> work (seemingly a related issue). If I get those same errors again, I'll 
> start another thread.

This certainly does all sound related. What are the ccache files called:
are they just /tmp/krb5cc_UID or is there a random portion as well? Are
they being created with the correct permissions, and are there any
security policies (SELinux or ACLs of some kind) set up which might
interfere with their creation or destruction? 

What happens if you log in as an ordinary user (preferably using the
same PAM stack as Dovecot uses), use klist to find the ccache name and
'ls -i' to find its inode number, then manually kinit again? Does the
kinit succeed, and does the new ccache have a different inode number
from before? Does the ccache file get removed when you log out?

Ben