Some Windows EXE will not run from WSL, returns Permission denied

[t3nk3y]

• Windows build number:
  Microsoft Windows [Version 10.0.17134.112]

• What you're doing and what's happening:
  Attempt to run an elevation required Windows based exe from bash console:
  $ ./setup-x86_64.exe
  Installer application opens UAC prompt, and works. Console also outputs this:
  note: Hand installation over to elevated child process.
  
  Attempt to run a a different elevation required Windows based exe from bash console:
  $ ./vcxsrv-64.1.20.0.0.installer.exe
  EXE does not execute, and returns an error
  ./vcxsrv-64.1.20.0.0.installer.exe: Permission denied
  
  These example executables can be obtained from their websites for free:
  setup-x86_64.exe
  From cygwin website. This is the cygwin 64bit installer.
  
  vcxsrv-64.1.20.0.0.installer.exe
  From vcxsrv SourceForge page.

• What's wrong / what should be happening instead:
  Some Windows executables run fine from WSL, others return Permission denied. This may be related to elevation being required, but I haven't been able to confirm that through testing.
  
  All Windows executables should run from WSL. Executables, that require elevation, should open the UAE prompt and continue after being confirmed.
  

• Strace of the failing command, if applicable:
  Let me know if an strace will help, and I'll sanitize and upload it.

[benhillis]

Yes, if the Windows binary you are running requires elevation and you are not returning elevation, the launch will return permission denied.

[t3nk3y]

Hi Ben. I understand that if the application requires elevation, that it won't run without it. My point is that some Windows EXE that DO require elevation open the UAC prompt to request elevation, and then run fine. However, other ones just throw permission denied, and the UAC prompt does not open. These same EXEs work fine when launching from Windows, they show the UAC prompt.

All EXE that require elevation should be causing Windows to open the UAC prompt.

[benhillis]

@t3nk3y - The ones that work are handling the case of being launched unelevated. The Cygwin installer prints a message to this effect. I can take a look at this to see if there's something we can be doing better.

[t3nk3y]

It sounds like you are saying that the software that works, is built to start unelevated, and then raise the prompt for elevation when needed. I considered this could be the case, however, logic would imply that it is not true. You see, if the software that doesn't work fails to do so because it is expecting to have elevated access, and isn't built to raise the UAC prompt, then, that software would also fail when run from explorer without elevation. But that isn't there case here, both types of software work in windows, and the UAC prompt opens for both.

This means that something about Windows(the shell, maybe explorer, something in the kernel) is interrupting the launch, injecting the UAC process in-between, and then elevating the rights for the processes that aren't designed for this. The fact that it fails with a perms error gives me the impression that there is software specifically designed to ask for elevation, and some that is not, and that in the case that it is not, WSL is testing the permissions, and rather than offering elevation, or to simply hand the launch off to windows(so it can use its process), it is instead, finding that privileges are insufficient, and preventing execution, despite the fact that windows would be more than happy to open the UAC prompt.

It sounds like it may have been an intentional design concept, as Linux is typically built to handle elevation through explicit requests to run as another user, as opposed to the OS offering elevation. But this is a flawed concept when applied to windows executables being launched from Linux, as the windows software was not built with any expectation that it might need to handle this. As similar as the concept of Sudo, and UAC may seem, they are not equivalent and shouldn't be treated as much.

Again, thanks for your time and efforts on this. Please take my statements as logical arguments, not as any sort of slight against anyone.

[koyae]

Edit: after encountering a similar issue, I found that my causes were different from OP's.

Changing the mounting options in /etc/wsl.conf to add execution bits to files by default solved my troubles. For me, this worked:

[automount]
enabled = true
options = "metadata,umask=0077,fmask=0077"

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!