Project review: GSS credential store extensions

Simo Sorce simo at redhat.com
Thu Jul 12 16:20:02 EDT 2012


On Thu, 2012-07-12 at 15:50 -0400, Sam Hartman wrote:
> >>>>> "Simo" == Simo Sorce <simo at redhat.com> writes:
> 
>     Simo> On Thu, 2012-07-12 at 12:43 -0400, Sam Hartman wrote:
>     >> >>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
>     >> 
>     >> Ok. Well, add me to Nico in the strong disagreement camp here.  If it
>     >> were just the buffers, I would agree with you.  
>     >> I'm actually a bit puzzled about why you're bringing up buffers though;
>     >> this structure does not include buffers.
>     >> 
>     >> My concern is the array
>     >> of pointers to buffers and what happens when you want to try and
>     >> manipulate them. My experience with memory management for oid sets
>     >> suggests this is an area where even in non-performance-sensitive areas
>     >> it gets really messy.
>     >> 
>     >> Even if Nico and I aren't able to build a consensus in favor of a better
>     >> memory management approach, I think it's critical that we document the
>     >> assumptions of this approach.  Namely, you cannot free a cred_set you
>     >> didn't allocate. You cannot manipulate one; you must copy to manipulate.
> 
>     Simo> In my view the cred_store is not something you manipulate within gssapi,
>     Simo> it's a configuration store for credential, not a 'communication means'.
> 
>     Simo> So leaving memory management to the application seem quite reasonable
>     Simo> and safe.
> 
> 
> I'm not OK with this, because I think it's entirely reasonable and
> desirable for a mech glue or stacked mechanism to  configure a mechanism
> it calls.

This does not not contradict what I said, in fact I agree with what you
say below.

> Given where people stand on these issues, I'm entirely fine saying that
> the mechglue or stacked mechanism needs to copy the cred store
> information to manipulate it. I'm also fine saying that the const char *
> strings are null terminated.
> I just think we need to write that down.

I am ok with writing down these points, as I agree with them fully.
Where should we write them ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the krbdev mailing list