How am I supposed to free the memory the system allocates in the SetPrivateObjectSecurity function?

A customer noted that the Set­Private­Object­Security function updates a pointer provided by the Objects­Security­Descriptor parameter. Since it may allocate a new security descriptor, that means that it needs to deallocate the old one. But what function does it use to free the old one? After all, the allocation function must match the deallocation function. Similarly, how should the new security descriptor be freed? (I say "similarly" because the two answers had better be the same!)

The system allocates and frees the security descriptor from the proess heap, as reported by the Get­Process­Heap function. The allocation function is Heap­Alloc and the deallication function is Heap­Free. That means that the security descriptor you pass in must have been allocated with

    SecurityDescriptor = HeapAlloc(GetProcessHeap(), flags, size);

and then you pass the pointer like this:

    SetPrivateObjectSecurity(..., &SecurityDescriptor, ...);
    // or
    SetPrivateObjectSecurityEx(..., &SecurityDescriptor, ...);

and after the Set­Private­Object­Security function is done, you must free the memory with

    HeapFree(GetProcessHeap(), SecurityDescriptor);

I wrote this post the same day that I submitted the change request to add this essential information to the documentation. We'll see who wins.

Comments (12)
  1. Brian_EE says:

    Looks like you win.

  2. camhusmj38 says:

    Looks like you won. If the lead time on your blogs is really 2 years then that is a shockingly slow update process.

    1. The lead time is only two months now.

  3. xcomcmdr says:

    Typo : proess -> process

    1. Dirk Gently says:

      deallication > deallocation

  4. skSdnW says:

    Does SAL have a tag to indicate which free function to use? _FreeFunc_(HeapFree) would be nice.

  5. Yukkuri says:

    YOU WIN!
    *score counter rolls*

  6. kantos says:

    It would be interesting to get some metrics on how many programs leak security descriptors as a result of the bad documentation

    1. cheong00 says:

      The information (use HeapFree() to cleanup) is actually provided in the example of the functions ( ) but I guess it’ll be more handy to include it in the individual function’s documentation themselves.

  7. Cesar says:

    In the same way on Unix you can usually assume malloc() unless stated otherwise, on Windows you can usually assume HeapAlloc(GetProcessHeap()) unless stated otherwise (except if it’s COM, then you must assume CoTaskMemAlloc instead).

    1. skSdnW says:

      No, I would bet that LocalFree is more common than HeapFree for classic Win32 functions where you must free the result.

    2. Joshua says:

      I’m surprised that MSVC*CRT (that is, any C runtime lib used by MSVC) never defined malloc and free to do just that. It’s hard to make a zlib.dll now because that library really wants there to be a platform malloc.

Comments are closed.

Skip to main content