How long do I have to keep the SECURITY_ATTRIBUTES and SECURITY_DESCRIPTOR structures valid after using them to create a file?


A customer passed a SECURITY_ATTRIBUTES when creating a file and wanted to know how long that structure (and the structures it points to) need to remain valid. "Do I have to keep them around as long as the handle that references the SECURITY_ATTRIBUTES remains open?"

No. Once Create­File returns, the SECURITY_ATTRIBUTES you passed in is no longer used. Everything the system needs was copied to a safe place as part of the Create­File operation. You are welcome to free the memory or to modify and reuse it in a future call to Create­File.

If you think about it, this is really the only way it could be. The file handle could be duplicated into another process, and then the original process might terminate. At that point, the memory for the SECURITY_ATTRIBUTES no longer exists, but there's still an open handle.

And there doesn't seem to be any benefit in relying on the copy of the security descriptor in the application's memory, because even if the kernel did that, the information would need to be copied from the application's memory into kernel space when the handle is closed. You may as well just copy it now. (And if the process crashes, the address space is destroyed, so the last known copy of the security descriptor is lost!)

File handles are kernel objects, and the kernel as a rule does not retain references to memory in user-mode. (With the obvious exception of output buffers, such as the buffer passed to Read­File or the OVERLAPPED structure passed to overlapped I/O.)

The customer confirmed that they didn't think it was necessary to keep the SECURITY_ATTRIBUTES valid, but they aer trying to figure out a bug and that was one of the crazy theories they had for why the problem might be occurring. They thanked us for confirming their understanding and went back to debugging their program, but now with one possible root cause ruled out.

Comments (3)
  1. skSdnW says:

    A more interesting question is; when can you free the memory backing the HSTRING you created with WindowsCreateStringReference?

    MSDN gives you a clue: “When passing a string reference into the Windows Runtime, it is the caller’s responsibility to ensure that the string’s contents are unchanging and NUL terminated for the duration of the call. The Windows Runtime releases all references to the string reference when the call returns.” It sounds pretty simple but all it takes is one bug somewhere in all of WinRT where someone forgets to duplicate a input string if they need said string later after the function has returned…

    1. Erik F says:

      Reading between the lines, I think that this statement means that string references aren’t thread-safe. The recommended behaviour for creating a string reference appears to be to create the string on the stack, make a reference, use it, and then delete the reference before going out of scope. The implied rule for callees then is to make deep copies of passed-in HSTRINGs with WindowsDuplicateString (notice what happens if you give that function a reference.)

  2. IanBoyd says:

    It’s always nice to see the reasons *why* something the way it is. It makes it easier to reason about things probably work in future situations.

Comments are closed.

Skip to main content