Sometimes you need to take a copy of a file that another program creates when it runs and subsequently deletes but it may well have deleted it before you get a chance to take a copy. A colleague was struggling with such an issue recently so I suggested temporarily changing the permissions on the folder where the file was created such that the file could be created but not deleted. This should then allow the file to be copied at your leisure since the creating program should be unable to delete it (unless it manipulates the file’s Access Control List (ACL) itself but this is unlikely).
Owing to my age, I like command lines, although I shudder if anyone dares to call a cmd prompt a DOS prompt, and in this instance it’s much easier to show what we need to do to secure the folder which is:
icacls %temp% /deny appsense\ivan:(CI)(OI)(DE,DC)
This creates a deny Access Control Entry (ACE) in the ACL for the folder, sub folders and files where the file is created, which you can figure out with good old Process Monitor (procmon). The “OI” and “CI” are Object Inherit and Container Inherit respectively and without these specified the ACE would only be added to the folder and not be inherited by anything created in there. The “DE” and “DC” are Delete and Delete Child respectively which are the special permissions which we are explicitly denying and as we all know in Windows security it’s the most restrictive permission that wins so a Deny ACE beats an Allow ACE. We assume that there is already an ACE in the folder’s ACL that allows the user, “ivan” in this example, to create files – the user’s %temp% folder, for instance, would normally have a Full Control Allow ACE for the user to which it relates.
Once the required file(s) have been moved elsewhere, the ACE added above should be removed by running:
icacls %temp% /remove:d appsense\ivan
Note that as long as the user “ivan” already has permission to change the ACL on the required folder then the above icacls commands do not need be run elevated. You can run icacls with just the folder name as an argument to see what the current ACL contains.
Before the more pedantic amongst you contact me, I should point out that I know I ought not refer here to an ACL but instead to to a DACL (Discretionary Access Control List) but most of the time when we talk about security of Windows objects the “D” is silent. After all, the utility is not called icdacls.exe! Also, don’t confuse a DACL with a SACL (System Access Control List) which contains audit settings, which you viewin Explorer’s security dialogues for NTFS objects for example.