Starting from a customer query, I looked more closely at nss_ldap's timeouts than I ever have before, and confirmed their assertion that it would block "forever" if you sent a SIGSTOP to the server. The client would connect at the TCP level, but its queries would go unanswered. Maybe at some point it would get a SIGPIPE, but I didn't check on that.

Turns out that while for the most part, nss_ldap uses asynchronous APIs which let it apply timeouts, in a couple of places it uses the synchrounous APIs, which wait indefinitely for responses from the server. And if those responses never come, we have a problem.

One of these was due to a limitation in libldap, which after a brief discussion, the OpenLDAP folks quite kindly implemented for future releases. The rest, well, is going to require a patch.

Somebody asked me today about comments in the pam_krb5 sources which indicate that refreshing credentials isn't be implemented because I don't have a good way to determine when it's safe to refresh them. At the least, it would include

• the process is neither setuid nor setgid
• SUDO_COMMAND isn't set (no "sudo su" wackiness, please)
• if KRB5CCNAME is set, it points to a real file which is owned and writable by the current UID, and not world writable
• the default principal in KRB5CCNAME is the principal which we're authenticating
• if KRBTKFILE is set, it points to a real file which is owned and writable by the current UID, and not world writable
• the default principal in is the principal which we're authenticating

Though I'm still not completely sure that's enough to guarantee safety.