rewrite gss_krb5_ccache_name

[Stephen Ince]

Douglas,
  Thx for the suggestion but that did not work. I think the old reference is 
for previous cache name. Same number of bytes leaked and purify complained 
that the memory was being freed twice.

Steve
----- Original Message ----- 
From: "Douglas E. Engert" <deengert at anl.gov>
To: "Stephen Ince" <since at opendemand.com>
Cc: <jaltman at secure-endpoints.com>; "krbdev" <krbdev at mit.edu>; "Jeffrey 
Hutzelman" <jhutz at cmu.edu>
Sent: Monday, November 24, 2008 11:01 AM
Subject: Re: rewrite gss_krb5_ccache_name


>
>
> Stephen Ince wrote:
>> Thx. Not really possible and has other side effects. We need the 
>> application needs to run as lean as possible. One thread consumes a lot 
>> of memory and will have to be around for the life of the program. At one 
>> point you could have 2000 threads and at another point 10 threads. We 
>> basically simulate browsers and their http connections.
>
>
> As a temporary fix, could you do something like:
>
> char * not_needed_name;
> gss_buffer_desc not_needed_buffer;
>
> not_needed_name = NULL;
> major_status =gss_krb5_ccache_name(&minor_status,
>                                       krb5_ccache_name,
>                                       &not_needed_name);
> if (not_needed_name) {
>    not_needed_buffer.length = strlen(not_needed_name)+1;
>    not_needed_buffer.value = not_needed_name;
>    gss_release_buffer(&minor_status, &not_needed_buffer);
>    not_needed_name = NULL;
> }
>
> This would then allow you application to get the string
> so it can be freeded, but let the gssapi lib use the free()
> function linked with the lib.
>
>>
>> Steve
>> ----- Original Message ----- From: "Jeffrey Altman" 
>> <jaltman at secure-endpoints.com>
>> To: "Stephen Ince" <since at opendemand.com>
>> Cc: "Jeffrey Hutzelman" <jhutz at cmu.edu>; "krbdev" <krbdev at mit.edu>
>> Sent: Saturday, November 22, 2008 10:54 AM
>> Subject: Re: rewrite gss_krb5_ccache_name
>>
>>
>>> 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
>>>>>
>>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> -- 
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
>