GSSAPI Murder authentication and "The context has expired" on long proxyd sessions

[Nik Conwell]

My frontends authenticate to the backends using GSSAPI.  Every 5  
hours the frontends do a kinit to get a TGT to talk to the backend  
and all is good.

However, if the frontend imap (proxyd) is proxying a session for more  
than 10 hours I get:

    imaps[3207]: GSSAPI Error: The context has expired (No error)

This seems to happen in cmd_idle() (probably spends most of its time  
there).  The frontend is in cmd_idle() having just received something  
from the user client to terminate the IDLE.  The frontend writes DONE 
\r\n to the backend but the write gets the context has expired error  
but it isn't checking for errors returns on the prot_printf().  The  
frontend then does a pipe_until_tag() waiting for the backend.   
Meanwhile the backend has seen nothing and so is still waiting for  
the frontend to terminate the idle.  Hung.

So, my questions are:

1) Should somebody (SASL?) be requesting an indefinitely long  
context?  gss_init_sec_context has an arg of the duration of the  
context.  My linux build (Thanks Simon) has 0 for the time_req which  
is evidently defaulting to 10 hours.  It could take GSS_C_INDEFINITE  
but it's not apparent that this wouldn't just end up being the life  
of the ticket (10 hours, 21 hours?).  I'm game to try this if it's  
not stupid.

2) Should somebody (SASL?  frontend proxy?) be creating new contexts  
automatically when the old ones expire?

3) Should cmd_idle() be just handling the error on the write to the  
backend and passing that back up to the client who will reconnect again?


BTW - my imapd is CVS:1.509.  I browsed the changelog for newer stuff  
but didn't see anything relevant.

Thanks for any info.
-nik

Nik Conwell
Information Technology
Boston University