On Fri, 2017-04-14 at 22:15 +0300, Isaac Boukris wrote: > On Fri, Apr 14, 2017 at 6:53 PM, Greg Hudson <ghud...@mit.edu> wrote: > > 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. > > Thanks for this information. > fwiw I also noticed rfc 2743 has the following comment about > gss_{init,accept} calls only: "this call may block pending network > interactions".
RFC2743 is generic, and with mechanisms different from krb5 gss_accept_sec_context() can indeed block. For example the NTLMSSP mechanism on a member server would have to contact the DC on accept() to be able to perform the challenge-response with the client. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos