CopyFileEx and ATTRIBUTE_SECURITY_INFORMATION

Dennis A 101 Reputation points
2021-08-21T23:12:40.883+00:00

I've noticed that since Windows 8, CopyFileEx is documented as copying DACLS along with the file itself; this was not the case in Windows 7. The Microsoft documentation I found for CopyFileEx notes that , "Security resource properties for the existing file are not copied to the new file until Windows 8 and Windows Server 2012."

What I cannot find is any way to disable this behavior. No flags or settings in CopyFileEx. This is problematic because:

  • I'm running in a Workgroup environment, not Domain
  • ACLs for files have both Well-Known (WKS) and Machine-Specific SIDS (MSS). The WSS are not a problem, but the MSS won't translate across the network.
  • The "old behavior" was for a file to take its ACLs from the folder into which it was copied, which is the behavior I'd like to restore!
  • I've written code to accomplish translating MSS between machines, so I can copy ACLs when I need to.

Perhaps I misunderstand what it means to copy the ATTRIBUTE_SECURITY_INFORMATION for a file. The only documentation I've found is for SECURITY_INFORMATION, which talks about ATTRIBUTE_SECURITY_INFORMATION as a value to set when reading or writing SACL ACE entries. If the ACLS are actually not copied, then my code will work. If the are copied, then I'd appreciate any documented or verified ways to keep CopyFileEx from copying the ACLS with the file.

Thanks!

Windows API - Win32
Windows API - Win32
A core set of Windows application programming interfaces (APIs) for desktop and server applications. Previously known as Win32 API.
2,566 questions
0 comments No comments
{count} vote

Accepted answer
  1. Dennis A 101 Reputation points
    2021-08-26T21:30:05.007+00:00

    Well before doing the work to change my code, I decided to run some tests. I used my code to add files to two different directories, one on the same drive and one on a different drive.

    Quick answer: CopyFileEx is NOT copying the ACLs from the Source directory/drive to the Target, be it on the same or a different drive.

    So despite the documentation, I can keep using my code as-is and it will work as designed.

    0 comments No comments

2 additional answers

Sort by: Most helpful
  1. RLWA32 44,746 Reputation points
    2021-08-21T23:40:38.947+00:00

    Both SHFileOperation and IFileOperation allow you to specify that security attributes should not be copied. Also, the CopyFile2 function does not copy security attributes.

    0 comments No comments

  2. Dennis A 101 Reputation points
    2021-08-22T22:57:01.137+00:00

    Thanks @RLWA32

    I'm hoping for something I can use with CopyFileEx -- I make use of several of its existing options. It seems so odd that MSFT would change the API behavior under the cover without offering a flag or setting to disable that new behavior.

    ... though barring that, CopyFile2 would probably offer the simplest changes -- so long as MSFT doesn't change this too. It would break Win 7 compatibility though (yes I have some Win 7 boxes that are blocked from the Internet), which would be a downside (unless I dynamically load entries with LoadLibrary & GetProcAddress and vary which call I use based on the Windows version -- a fair amount of work to get around this).

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.