I run Windows 10 and I would like the contents of my system default "Downloads" folder to be non-executable. I want at least for a landing zone where I can scan files, run hash checks, and so on.

Does this sound right?

Change the SYSTEM (and my own) permissions on that folder to eliminate "READ AND EXECUTE" while leaving READ intact.

I want to have to move files out of there in order to do more. (The user is always the biggest threat, so let's throw a stumbling block in my -- er "his" way.)

I am not looking for mathematical rigor - I just want a common-sense, easily obtainable LZ, and I would like for it to be the existing Downloads folder that the system recognizes.

  • I haven't been day-to-day on a Windows machine in a while, but isn't this what ZoneID's are for? woshub.com/…
    – nbering
    Apr 15, 2018 at 10:03

2 Answers 2


Changing permissions on the directory is probably the best way to go, yes. In addition to being relatively easy, it has the perk of acting more like the way most Unix-like systems work, where new (in this case, downloaded) files are not executable by default. Win32 has no equivalent of the umask, but you can fake it using directory inheritance (which Unix mostly doesn't use).

A few things to bear in mind when doing this:

  • NTFS ACLs support both "allow" and "deny" entries, for both users and groups. They are evaluated in the following order: user deny > user allow > group deny > group allow. In other words, a deny on a specific user always wins, but an allow on a specific user beats a deny on a group the user belongs to, but if the user neither has allow nor deny entries then if any of the user's groups have a deny then this trumps any allows that the user's group has. If neither user nor any of the user's groups have either allow nor deny entries, the default is to not allow (deny).
  • NTFS supports permission inheritance, where an object (file, directory, reparse point, etc.) can have some permissions inherited from its container (directory). In fact, this is the way most permissions in NTFS are set; relatively few object have explicit ACLs. Note also that an object can disable inheritance (it doesn't get its container's ACLs), an ACL can be non-inheritable (contained objects won't get it, even though they have inheritance enabled), and an ACL can be inherit-only (meaning it doesn't apply to the container, only to those of its contents that allow inherited ACLs).
  • Following the rule of "specific beats general", an explicit ACL on an object overrides the inherited ACL if there are conflicts. As such, even if the Downloads folder doesn't give its contents the Execute permission (or indeed, denies it), any particular file within Downloads might still gain that permission by explicit ACL.
  • NTFS, like most file systems, re-uses the Execute permission bit on a file as the Traverse Directory permission bit. As such, removing (or denying) Execute on the Downloads directory would normally prevent you from accessing any of its contents (you could list them, so long as you still had Read permission, but couldn't read or write them, etc.). However, Windows by default ignores Traverse permission checks (you can turn this behavior off, if you want), relying on Read/Write/etc. instead. This behavior means you can have weird things, like a directory structure A\B\C\D.txt where the user has no access at all to A, B, or C, but can read and even edit D.txt so long as the permissions on that file grant such access (and the user knows the exact path). It also means that, for directories, the Execute/Traverse bit basically does nothing except for inheritance purposes.
  • While the Execute permission on PE-format files (.EXE, .DLL, .SYS, etc.) acts like you'd expect, the default action on many other "executable" file types that are actually executed through some program (.BAT, .JAR, .PY, .JS, possibly even .MSI. etc.) will be ignored by the OS; such files only need Read permissions, and only their interpreters/runtimes/etc. need Execute permissions.

With all that said: setting a Deny permission on Execute/Traverse for the Everyone group on the Downloads directory (and making sure it's an inheritable permission, though by default it should be) should mostly do what you want.

  • .SHS, .COM , (html script files if run locally have full permissions) VBS, JS, .hlp, .chm .HTA , Apr 16, 2018 at 13:35
  • @MichaelEvanchik are you claiming those file types do, or do not, respect the Execute permission? Because .COM is used for executable x86 machine code (16-bit DOS code that won't run on 64-bit systems, but still) that runs directly, but the other file types you listed all execute through an interpreter/runtime, such as Windows Script Host. EDIT We both missed one: .SCR is an executable PE binary, basically identical to a .EXE except specifically for use with screen savers.
    – CBHacking
    Apr 17, 2018 at 22:16
  • that do, include many more, just was blurting out a few @CBHacking Apr 18, 2018 at 13:24
  • 1
    @CBHacking, I have poked around using your information. I now see what you mean, and am a little terrified of locking myself out entirely. I have three security principals with access to the folder; SYSTEM, Admins group, and my own SID (helpfully named S-51-blah-blah-blah). Should I set READ AND EXECUTE to Deny for the Admins group, and then explicit allow READ on my personal SID? Or am I making this needlessly complex? --- I want to prevent "me" (or process using my context) from simply executing something in that folder. It should be moved out first.
    – user99573
    Apr 29, 2018 at 21:48

I think you are on the right path. Modify ownership and restrict permissions appropriately.

You can also use Controlled Folder Access from the Windows Defender Security Center. Which will allow you to limit what applications can access that folder.



You can also do this sort of thing with most endpoint security suites.

You must log in to answer this question.