Bug 132272

Summary: IMAP with PAM_KRB5 doesn't delete Tickets in /tmp
Product: Red Hat Enterprise Linux 3 Reporter: Jason Sauve <jasonsauve77>
Component: imapAssignee: John Dennis <jdennis>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-16 19:57:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 123574    

Description Jason Sauve 2004-09-10 15:00:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; 
SV1; .NET CLR 1.1.4322)

Description of problem:
Using IMAP with PAM_KRB5 will leave all tickets in /tmp saved as 
krb5cc_*****_***** and never remove them, eventually filling up the 
free space and free inodes on a production sever very quickly where 
imap/pop3 is used heavily.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Enable pam_krb5 and use POP3 to check using KRB5 account credentials. 
IMAP will not delete leftover kerberos tickets 
in /tmp/krb5cc_####_######.

Actual Results:  Thousands of kerberos tickets created in /tmp

Expected Results:  Kerberos tickets to be removed from /tmp

Additional info:

I've verified that the problem occurs with all combinations of the 
following packages installed.

imap-2002d-9, imap-2002d-8, and imap-2002d-2
pam-0.75-54, pam-0.75-58 
krb5-workstation-1.2.7-28, krb5-workstation-1.2.7-24

Comment 1 Jason Sauve 2004-09-10 17:06:39 UTC
Here is an article I found that describes with more detail my problem 
origin is http://archives.neohapsis.com/archives/pam-list/2003-

On Thu, Oct 23, 2003 at 04:01:14PM +0100, David Lee wrote: 
> OS: Mostly Redhat 9 but also Solaris 8. PAM/krb5 details at end of 

> Although our passwd information on those RH and Solaris machines 
uses NIS, 
> we recently migrated the authentication aspect from NIS to Kerberos 
> Active Directory). 

> Since then I have noticed that each machine's "/tmp" contains lots 
> files with names of the form "/tmp/krb5<NIS-domain>_<uid>_<random>" 
> Redhat (on Solaris it is the simpler "/tmp/krb5<NIS-

> These seem to persist for days after the session that generates 
them has 
> gone. Generally this is not a problem. But our email machines have 
> very high daily quantity of IMAP and POP sessions, so the sheer 
> of these files has a significant impact on filespace (we currently 
> over 350,000 such files on one machine). 

> Presumably these files have no relevance after the initiating IMAP 
or POP 
> session has gone away. Is there something we can do in PAM (or 
> or elsewhere) so it tidies up after itself? Have we missed 

> Currently we have (on Redhat): 

> /etc/pam.d/imap: 
> auth required pam_stack.so service=system-auth 
> account required pam_stack.so service=system-auth 
> /etc/pam.d/pop: 
> auth required pam_stack.so service=system-auth 
> account required pam_stack.so service=system-auth 

Looks familiar. Whenever I've seen this problem, it's been a bug 
(deficiency) in the application, rather than the PAM module. It's 
common with "sessionless" services, like POP and IMAP, which tend to 
call the PAM open calls and not clean up after themselves on the way 
out. A call to pam_setcred(PAM_DELETE_CRED) is almost certainly 
missing here. 

Comment 2 Jason Sauve 2004-09-10 18:39:56 UTC
Ok. There is DEFINATELY a problem with PAM kerberos ticket cleanup in 
the UW IMAP code.

I added the pam_setcred (hdl,PAM_DELETE_CRED); line below the 
comment "// Added by Jason on 2004-10-10" to the source 
file "/src/osdep/unix/ckp_pam.c", and "/src/osdep/unix/ckp_pmb.c" as 
well for when PAM authentication succeeds. The code already performed 
a proper cleanup on a PAM failure. However, if PAM authentication 
succeeds there is no need for the kerberos ticket any longer. Without 
my modification, the PAM library is not called to do any ticket 

Can someone PLEASE confirm that this resolution is acceptable and 
provide a RHN fix as I'm not a source maintainer for either PAM or UW 
IMAP. This is a serious issue for production level servers that use 
UW IMAP coupled with PAM_KRB5 as EVERY individual POP3/IMAP access 
causes disk space and inodes to be rapidly consumed under /tmp

struct passwd *checkpw (struct passwd *pw,char *pass,int argc,char 
  pam_handle_t *hdl;
  struct pam_conv conv;
  struct checkpw_cred cred;
  conv.conv = &checkpw_conv;
  conv.appdata_ptr = &cred;
  cred.uname = pw->pw_name;
  cred.pass = pass;
  if ((pam_start ((char *) mail_parameters (NIL,GET_SERVICENAME,NIL),
                  pw->pw_name,&conv,&hdl) != PAM_SUCCESS) ||
      (pam_set_item (hdl,PAM_RHOST,tcp_clientaddr ()) != PAM_SUCCESS) 
      (pam_authenticate (hdl,NIL) != PAM_SUCCESS) ||
      (pam_acct_mgmt (hdl,NIL) != PAM_SUCCESS) ||
      (pam_setcred (hdl,PAM_ESTABLISH_CRED) != PAM_SUCCESS)) {
                                /* clean up */
    pam_setcred (hdl,PAM_DELETE_CRED);
    pam_end (hdl,PAM_AUTH_ERR); /* failed */
    return NIL;
  // Added by Jason on 2004-10-10
  pam_setcred (hdl,PAM_DELETE_CRED);
#if 0
   * Some people have reported that this causes a SEGV in strncpy() 
   * pam_unix.so.1
   * This pam_open_session() call is inconsistant with how we handle 
   * platforms, where we don't write [uw]tmp records.  However, 
unlike our
   * code on other platforms, pam_acct_mgmt() will check those 
records for
   * inactivity and deny the authentication.
  pam_open_session (hdl,NIL);   /* make sure account doesn't go 
inactive */
                                /* arm hook to delete credentials */
  mail_parameters (NIL,SET_LOGOUTHOOK,(void *) checkpw_cleanup);
  mail_parameters (NIL,SET_LOGOUTDATA,(void *) hdl);
  return pw;

Comment 3 John Dennis 2004-09-10 20:58:34 UTC
Thank you for reporting the bug and your diligent work in diagnosing
the problem Jason. At first blush your suggested fix sounds correct.
I'll investigate and confirm. 

I'm not sure yet how we'll handle the fix, it will either be in a RHEL
update or an errata. An errata is a more likely vehicle but be aware
that the errata process for bug fixes as opposed to security takes a

Comment 4 dff 2004-09-13 17:32:05 UTC
Add to TaroonU4Candidates per jdennis request.

Comment 5 Jason Sauve 2004-09-13 17:39:15 UTC
I've noticed that in the ckp_pam.c there is a hook upon user logout 
or disconect that is supposed to take care of PAM ticket cleanup 
which is not working. 

The mail_parameters lines near the end of checkpw() seem to want to 
set this hook up. However the checkpw_cleanup() hook also in 
ckp_pam.c is not executing at logout/disconnect time (why - I do not 

I spoke with the Mark Crispin of UW-IMAP and he said that the logout 
hook method was supposed to be the proper way to clean up PAM 
tickets, otherwise UW IMAP will fail to work with DFS.

Comment 6 John Dennis 2004-09-16 18:46:20 UTC
O.K. that was a little confusing, the code you were talking about with
the hook is not in the version we ship (2002d), but it does look like
its in the current version. Unfortunately 2002d is the last version of
UW imap we will ship (its been deprecated in favor of cyrus-imapd or
dovecot). That means the hook code is a moot point from our perspective.

Your addition of pam_setcred (hdl,PAM_DELETE_CRED) seems fine and I'm
more that happy to patch our version to add that. I assume you've been
running with that patch now for a few days, has it been robust for you?

Comment 7 John Dennis 2004-09-16 19:57:13 UTC
I turned on pam_setcred (hdl,PAM_DELETE_CRED) at the end of the
checkpw function. I created the following bug fix errata: RHBA-2004:483-01

Comment 8 Jason Sauve 2004-09-17 03:40:01 UTC
You're correct. the 2002d-9 code that's shipped with RHEL 3 U3 
doesn't contain the logout hook code. I think I looked at the 2002e 
source that I had sitting around which did contain it - sorry about 
the confusion.

Anyways, the aforementioned fix has been working without any hiccups 
since I've recompiled. Kerberos tickets are now cleaned up nicely.