rewrite gss_krb5_ccache_name

[Jeffrey Altman]

You do not need to write this function.   That is not the bug you are
experiencing.
The bug is the library's failure to deallocate memory assigned to Thread
Local Storage.
You are not using the 'old_name' parameter set to anything other than NULL.

The way to avoid this problem is to redesign your application to use a
pool of pre-existing worker threads instead of spinning off a new thread
for each connection and letting it die when the application terminates. 
This solution would also use less CPU.

Jeffrey Altman

Stephen Ince wrote:
> Is there a work around for this? Can I write my own
> xgss_krb5_ccache_name? Or can I force a free?
>
> ----- Original Message ----- From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
> To: <jaltman at secure-endpoints.com>
> Cc: "Stephen Ince" <since at opendemand.com>; "krbdev" <krbdev at mit.edu>;
> <jhutz at cmu.edu>
> Sent: Saturday, November 22, 2008 12:13 AM
> Subject: Re: rewrite gss_krb5_ccache_name
>
>
>> --On Friday, November 21, 2008 11:57:54 PM -0500 Jeffrey Altman
>> <jaltman at secure-endpoints.com> wrote:
>>
>>> Note that there is a second problem with this api.  When a non-NULL
>>> 'old_name' parameter is provided, it must be freed using the same
>>> free() as is linked to the gssapi32.dll library.  Unfortunately,
>>> there is no gss_krb5_free_ccname() function in the API available
>>> to make sure that this is possible.  As a result, passing anything
>>> other than NULL as the 'old_name' parameter is dangerous on Windows.
>>
>> This is indeed a bug in the API.  The old_name parameter should never
>> have been a char **; it should have been a gss_buffer_t, which would
>> have allowed it to be released using gss_release_buffer().
>>
>> -- Jeff
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081122/00ff882f/attachment.bin