On 04/14/2017 08:26 AM, Isaac Boukris wrote: > If I only acquire credentials for krb5 mech, can I assume that > gss_accpet would not block on IO?
I think that's true, assuming the keytab and profile and /etc/gss/mech file aren't on a network filesystem. In the future we might have pluggable keytab types, at which time a keytab module might do blocking I/O, but that would be an exotic case. > Is there any information available on which gss calls may block on IO > and which not? I'm not aware of a writeup. From memory: gss_acquire_cred() and gss_init_sec_context() can block on either DNS or AS/TGS operations. The per-message functions shouldn't block. gss_inquire_cred() can be less trivial that it sounds (because it can force a resolution of which ccache to use which would ordinarily be delayed until init_sec_context) but I don't think it does network I/O (unless there's a ccselect plugin module which does so, or $HOME/.k5identity is on a network filesystem). The other inquire functions shouldn't block. The delete/release functions shouldn't block. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos