[20429] in Kerberos_V5_Development
Re: Parallel gss_get_mic or gss_wrap results in segfaults in
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Apr 19 13:54:11 2023
Message-ID: <24de0c82-2117-f28c-b0a5-8b662527a77d@mit.edu>
Date: Wed, 19 Apr 2023 13:52:52 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Amit Kale <amit.kale@cohesity.com>, krbdev@mit.edu
From: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <CAGdY9O3AWrg9fWnXq4fdmOfKk6Qde3uSJi1L=v2-G06a-VMbhw@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
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
