GSS memory allocation initial cut for review

[Jeffrey Altman]

On 9/28/2011 3:50 PM, Sam Hartman wrote:
> 
> Hi.  One of the problems with using GSS-API mechanism plugins on
> Windows is that the malloc provided by the C runtime requires that you
> free allocations in the same dll as you allocate them.  (It's more
> complicated than that, but if you follow that rule it works.)

I agree with the problem description.

> This means that if you allocate a buffer in a mechanism, that
> mechanism needs to release it.  That makes implementing
> gss_release_buffer difficult.  In theory you could copy buffers in the
> mechglue, or register pointers in the mechglue.
> 
> We're proposing an alternative. We're proposing that on a given
> platform we use a well defined allocator for GSS mechglues and
> mechanisms.  We don't think it is sufficient for a mechglue layer to
> export an allocator for mechanisms to use. We think it will common for
> multiple mechglues to be used in the same process and somewhat common
> in that case for the same third-party mechanism to be loaded by
> multiple mechglues.  So, we actually think we need to standardize on
> an allocation strategy.
> The question of whether we need a platform-global GSS allocator is a question for kitten and I'll eventually get around to bringing it up there.

I do not believe that it is acceptable to require that all GSS mechglue
layers on a given platform use the same allocator.  I agree that it will
be common for multiple mechglue layers to be present in a given process.
The obvious example is IIS which can load hundreds of independently
developed application modules each of which might be developed against
an independently developed GSS stack.   The reason that Asanka and I
have pushed for the use of side-by-side assemblies on Windows is to
permit the deployment of independent GSS and Kerberos stacks within an
application to become a possibility.

Adding a requirement that all GSS stacks and all mechglue layers and all
GSS mechanisms use a system-wide allocator will certainly address the
problem but at a significant cost to the freedom of GSS stack
developers.  By requiring that a particular allocator be used, you are
ruling about the ability to use custom allocators for memory debugging
or any other purpose.

For starters, I'm not sure I agree that it should be considered safe for
a single instance of a mechanism to be shared across multiple mechglue
implementations since at present there is no standardized mechglue
interface across all implementations.  The mechglue interface is a
contract between the mechglue provider and the underlying mechanisms.
There is no guarantee that this contract is the same across all mechglue
implementations nor do I believe that there is a need for there to be.

Perhaps I am misunderstanding you but it sounds like what you want is a
mechanism to be loaded as a plug-in to both MIT X and Heimdal Y and for
that mechanism to be able to use the allocator it obtained from MIT X
when allocating buffers to be used by Heimdal Y.  If so, I think this is
a recipe for disaster.

If you are attempting to solve a different problem, I would appreciate
it if you could attempt to explain it a second time with a bit more
detail related to the flow of buffer allocation and deallocation within
the process.

Thank you.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110928/fd5d46e4/attachment.bin