How am I supposed to free the information passed to the SetSecurityInfo function?

Some time ago, we discussed how you're supposed to free the information returned by the Get­Security­Info function. But what about the information passed to the Set­Security­Info function? "How do I free that?"

You free that memory by whatever means you like. You allocated the memory originally, so you get to free it. If you allocated the memory with malloc, then use free. If you allocated the memory with new, then use delete. Whatever mechanism you used to allocate the memory, use the corresponding mechanism for freeing it.

"Do I have to free the old DACL being replaced?"

No, that is managed by the system. What you're doing is saying, "Dear operating system: Here is a kernel object and some security information. Please set the security on the kernel object to match the information I'm giving you. Thanks."

"So you're saying that if I have code that does this:

  • Get­Security­Info(…, &oldAcl, …)
  • Create newAcl by copying the oldAcl and making appropriate changes.
  • Set­Security­Info(…, newAcl, …)

then I need to free the newAcl but not the oldAcl?"

No, that's not what I'm saying. I'm saying that the call to Set­Security­Info does not create any new obligations to free memory. However, it also does not destroy any existing obligations to free memory.

Calling Get­Security­Info created an obligation to free oldAcl. That obligation was not changed by the call to Set­Security­Info.

What I mean by saying that you don't have to free the old DACL being replaced is that when you call Set­Security­Info, the system frees its internal security info and replaces it with a copy of the security info you passed in. You don't need to worry about freeing that internal info. (Not that you could, because you don't know how it was allocated.) But of course, if you made a copy of the internal security info, then you are on the hook for freeing the copy.

Let's look at it this way:

  • There is some secret security info out there managed by space aliens from the planet Krypton. You do not have direct access to it. The only way to access it is by calling functions like Get­Security­Info and Set­Security­Info.
  • The Get­Security­Info function says, "Dear space aliens: Please take your security info, translate them from Kryptonese to Win32, and give me the translation. I will free the translation when I'm done."
  • The Set­Security­Info function says, "Dear space aliens: Here is some security info in Win32 format. Please translate it to Kryptonese and use that as the new security info."

You don't speak Kryptonese, but that's okay, because your only interaction with the security info is through Win32 format. If you ask for a copy of the internal security info, then you are responsible for freeing that copy. But the internal Kryptonese security info is not something you need to worry about. The space aliens will take care of that.

Comments (8)
  1. skSdnW says:

    This should not be a surprise to most people, what does surprise me however is this little warning on the bottom of the MSDN documentation: “If the supplied handle was opened with an ACCESS_MASK value of MAXIMUM_ALLOWED, then the SetSecurityInfo function will not propagate ACEs to children.”

    If you are able to get the required access rights, why does it matter how you ask for those rights?

    1. It seems to be an example of something being named for what it is, rather than what it’s for. Its use triggers various special cases across the ACL function family.

      “Of special note is the MAXIMUM_ALLOWED bit, which is generally used with the AccessCheck(…) function to determine whether a security descriptor grants a specified set of access rights to the client identified by an access token. Typically, server applications use this function to check access to a private object.”

      1. skSdnW says:

        I don’t think the MAXIMUM_ALLOWED bit is set in the handle? It probably maps to the access you get when you create the handle.

  2. Nick says:

    OK, got it.
    Space aliens invented Win32.

    1. Yet they still couldn’t get that time machine…

      1. D-Coder says:

        Time machines are forbidden by the Splotnakian Treaty of 301893.

        Doesn’t everyone know that????

        1. Joshua says:

          Thankfully, the USA isn’t a party to that treaty.

  3. JM says:

    “It’s not an S. On my world it means ERROR_SUCCESS.”

Comments are closed.

Skip to main content