[37955] in Kerberos
Re: Which gss calls may block on IO
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Fri Apr 14 15:16:06 2017
MIME-Version: 1.0
In-Reply-To: <ac9cb741-ef98-f691-541a-263a04d10171@mit.edu>
From: Isaac Boukris <iboukris@gmail.com>
Date: Fri, 14 Apr 2017 22:15:51 +0300
Message-ID: <CAC-fF8Q6XCG6vpvH_7D6hXv-=1w1yx2zCkSJtkiZrBL47AyS5Q@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Fri, Apr 14, 2017 at 6:53 PM, Greg Hudson <ghudson@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".
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
