Which gss calls may block on IO
ghudson at mit.edu
Fri Apr 14 11:53:49 EDT 2017
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.
More information about the Kerberos