[20431] in Kerberos_V5_Development
Re: Parallel gss_get_mic or gss_wrap results in segfaults in
daemon@ATHENA.MIT.EDU (Amit Kale via krbdev)
Tue Apr 25 23:56:05 2023
MIME-Version: 1.0
In-Reply-To: <24de0c82-2117-f28c-b0a5-8b662527a77d@mit.edu>
Date: Wed, 26 Apr 2023 09:24:55 +0530
Message-ID: <CAGdY9O00YvcbBS_jXD2LQEuMA7fv5--9bNQ9vKzJ7uthcd3wXQ@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev@mit.edu
From: Amit Kale via krbdev <krbdev@mit.edu>
Reply-To: Amit Kale <amit.kale@cohesity.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Thanks for this info. It appears that we'll need to do some
investigation to figure out the extent of this issue. We're doing more
testing and will continue to post our findings and
suggestions/patches.
-Amit
On Wed, Apr 19, 2023 at 11:22 PM Greg Hudson <ghudson@mit.edu> wrote:
>
> On 4/19/23 01:07, Amit Kale via krbdev wrote:> We're trying to use mit
> kerberos library for NFS encryption.
> > Running gss_get_mic in two threads with the same gss context results
> > in following segfault.
>
> The majority of the thread-safety work in the MIT krb5 libraries
> predates my tenure and it isn't fully documented, but it looks like
> there has never been a deliberate attempt to make GSS context handles
> safe when used simultaneously in multiple threads. In addition to the
> use of krb5_key objects which (deliberately) aren't internally locked,
> there is also mutation of the sequence numbers and sequence states. I
> think this hasn't come up before because most protocols using GSS
> message protection are inherently sequential, so it rarely makes sense
> to produce or process messages in parallel within a context. But the
> GSSAPI is intended to support non-sequential protocols, so there would
> be some value in making this work.
>
> Heimdal has internally locked context handles, and limits the critical
> section to sequence number handling. Adding a lock to the MIT krb5
> context structure should be straightforward, but limiting the critical
> section would be harder due to the krb5_key type.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
