Wasmer cli requires admin privilege on Windows due to cache

[rajsite]

Describe the bug

Trying to run a wasm module with the wasmer cli in a normal user level cli results in:

> wasmer exorbitant.wasm
error: failed to run `exorbitant.wasm`
│   1: module instantiation failed (engine: universal, compiler: cranelift)
╰─> 2: Access is denied. (os error 5)

Windows 10 using Wasmer 2.0 installed from the Windows Installer in the release.

Steps to reproduce

From a user-privilege cli run: wasmer <some wasm file>

Expected behavior

I expect the cli to be able to run and cache build results in user accessible folders. I do not expect to need admin privileges to run wasmer.

Additional context

Workarounds:

1. In a user-privilege cli disable the cache:

   wasmer run --disable-cache exorbitant.wasm

2. Run from a cmd with admin privledges:

   1. Press start and type cmd
   2. Right click on the "Command Prompt" option and choose "Run as administrator" (approve the UAC prompt as needed)
   3. Run wasmer in the admin prompt

Edit: The wasm file used: https://wapm.io/package/rajsite/exorbitant

[chenyukang]

I will have a try on this issue since most of you are using MacOs ...

[chenyukang]

Confirmed the bug.
This is introduced by this PR

If we use:

Root: HKCU; Subkey: "Environment"; ValueType:string; ValueName: "WASMER_CACHE_DIR"; \
    ValueData: "{app}\cache"; Flags: preservestringtype

The WASMER_CACHE_DIR will be: "C:\\Program Files (x86)\\Wasmer\\cache\\2.0.0"
And we can not create directory in it: "C:\\Program Files (x86)\\Wasmer\\cache\\2.0.0\\cranelift"

This line will trigger an error.

@syrusakbary , why did we replace {%USERPROFILE} with app?

[syrusakbary]

@chenyukang I did it that way because a user may have different versions of Wasmer installed in different folders and I wanted to associate the configuration with the installation. This was required for testing choco if I remember properly.

However, I did not know that would trigger an error though.

We can roll back partially that commit, or think on other solutions?

[chenyukang]

WASMER_CACHE_DIR is only used for caching Store, so I think it's better not to set a register default value for it on Windows. We can keep the consistent usage style with Unix/Linux OS.

If users want to specify a cache directory, they can set an environment variable WASMER_CACHE_DIR, otherwise, env::temp_dir() will be used and it's safe for caching files.

/// Get the cache dir
pub fn get_cache_dir() -> PathBuf {
    match env::var("WASMER_CACHE_DIR") {
        Ok(dir) => {
            let mut path = PathBuf::from(dir);
            path.push(VERSION);
            path
        }
        Err(_) => {
            // We use a temporal directory for saving cache files
            let mut temp_dir = env::temp_dir();
            temp_dir.push("wasmer");
            temp_dir.push(VERSION);
            temp_dir
        }
    }
}

What do you think?