Which gss calls may block on IO

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Which gss calls may block on IO

Isaac Boukris
Hello,

If I only acquire credentials for krb5 mech, can I assume that
gss_accpet would not block on IO?
Is there any information available on which gss calls may block on IO
and which not?

Thanks!
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Which gss calls may block on IO

Greg Hudson
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Which gss calls may block on IO

Isaac Boukris
On Fri, Apr 14, 2017 at 6:53 PM, Greg Hudson <[hidden email]> 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".
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Which gss calls may block on IO

Simo Sorce-3
On Fri, 2017-04-14 at 22:15 +0300, Isaac Boukris wrote:

> On Fri, Apr 14, 2017 at 6:53 PM, Greg Hudson <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Loading...