Elevation broke between 1.1.7 and 1.1.9

[WORMSS]

Issue:
1.1.9 no longer pops up UAC to asks to to change node/npm, it just FAILS straight away with exit status 5: Access is denied

How To Reproduce:

1. Have version 1.1.7 installed.
2. nvm use 17.4.0
3. UAC comes up, do you want to change node (yes)
4. UAC comes up, do you want to change npm (yes)
5. (observe everything is good with the world)
6. Install NVM 1.1.9 from nvm-setup.zip or nvm-update.zip
7. nvm use 17.6.0
8. 💥 exit status 5: Access is denied. 💥
9. 😢 cry because the world is caving in 😢

Expected Behavior:
To do step 3 and step 4 in 1.1.9, just like 1.1.7 used too.

Just to note, this does the EXACT same thing in CMD also..

Work around, I open a CMD window as administrator, and it works. But this is a major ballache to do.

Windows: 10.0.19044.1526

[WORMSS]

Just to note... Installing 1.1.7 makes things work again..

It doesn't matter if you use nvm-update.zip and select "1.1.9" or nvm-setup.zip (1.1.9) they both break.

But rolling back to 1.1.7 works wonderfully

[dgchrt]

Work around, I open a CMD window as administrator, and it works. But this is a major ballache to do.

Probably not what you want though, as this will potentially prevent the unprivileged user account from managing it in the future.

[WORMSS]

Well... yeah... that is why I opened it as administrator... to get around the fact that the unprivileged user account couldn't do it..
I didn't install node as admin.. I just needed admin to use nvm.. Hence it was a ballache.
But as I said.. the best work around I found was installing nvm-windows 1.1.7.. works a treat.

[poindexterous]

I've run into this also, I was upgrading from NVM 1.1.6 to 1.1.9 (upgraded to try and fix some bugs I was running into) and I ran into the same problem as @WORMSS when trying to switch node versions in powershell where the UAC prompt no longer popped up for NVM and gave me the exit status 1: Access is denied. message.

I'm trying to avoid opening up a separate elevated powershell just to switch my node version, but right now it seems like the only way without downgrading. Sadly I can't run everything from an elevated powershell due to user ssh key differences, and user file ownership issues with my everyday work user account and the separate admin account I have (which should only be used for elevation as needed). My company's IT department gets - understandably -nervous if I run everything on the local admin account, they prefer I use it sparingly.

[dgchrt]

Just use 1.1.7 for now, as I've pointed out here: #700 (comment)

[ojintoad]

@diogoeichert That's a good suggestion for those who want to go that route, but there are a number of benefits of using post 1.1.7 releases according to the release notes. A signed installer is a big one for some orgs.

I'm sure Corey is busy with his rt tool - this might be a good item for someone else to try to work out. 🤞

As an additional workaround, there are tools that enable "sudo" like functionality that present UAC prompts. I just tested successfully with gsudo for example:

C:\Users\ojint
> gsudo -d nvm use 10.17.0
Now using node v10.17.0 (64-bit)
C:\Users\ojint
> nvm list

    10.24.1
  * 10.17.0 (Currently using 64-bit executable)
C:\Users\ojint
> gsudo -d nvm use 10.24.1
Now using node v10.24.1 (64-bit)
C:\Users\ojint
> nvm list

  * 10.24.1 (Currently using 64-bit executable)
    10.17.0
C:\Users\ojint
>

Each time I ran gsudo it presented me with a UAC prompt. The tool is sophisticated enough to not reprompt either, but that has its own security risks/concerns. Personally if I were to continue using it I'd try to stick with constant prompting.

There are other similar tools besides gsudo worth considering, though gsudo seems like it's at least more recently maintained. Depending on your situation this may be a decent workaround as well.

[dgchrt]

@ojintoad Nice, I wasn't aware such tools existed for Windows already. Thanks for sharing.

[ojintoad]

I need to go to bed but figure I would speak to how far I got in trying to understand this. I'm not quite sure I want to open a PR. This is the first time I've touched Go as a language and the first time I've touched this library so any assumptions I'm making come with a big caveat.

First, I am slightly confused about what the runElevated command is supposed to try to do. I think that it might have been intended to be slightly differently written and to call itself in a way I'm not sure it does now.

https://github.com/coreybutler/nvm-windows/blob/5803c4f8c7766c670996fbce3fc113a9b0d95050/src/nvm.go#L891-L897

I think the intent might have been to have 893 have a !uac check and for 894 to pass in true for the forceUAC parameter. That would sort of make sense - if we failed to run the command without the uac check process, then let's force the issue. I started out trying that and sure enough it entered the earlier block in the method that tries to execute the command a different way.

https://github.com/coreybutler/nvm-windows/blob/5803c4f8c7766c670996fbce3fc113a9b0d95050/src/nvm.go#L866-L877

That hits a new problem when trying to do nvm use. First, the variable command already has the path to elevate.cmd in it from earlier so now it's going to get double included. So you get an error like this:

But even if you remove that, it appears to fail to call correctly in a different way since the elevate.cmd really doesn't appear to like having parameters passed in as a straight string. So you get an error like this:

Edit - additionally if you just pass the command without passing the joined path to the elevate.cmd file, it still errors in a different way:

exec: "\"[C:\\Users\\ojint\\AppData\\Roaming\\nvm\\elevate.cmd\]()" cmd /C mklink /D \"[c:\\nodejs\]()" \"[C:\\Users\\ojint\\AppData\\Roaming\\nvm\\v10.17.0\]()"": file does not exist:

That somewhat surprises me as I think the other commands do get passed that way, so there's something specific about that command or I'm missing something about how it works.

Regardless of why it's failing, we want to still try to call that command to make the symlink in a way we know that works. We know that 1.1.7 works. If we look at the 1.1.7 version, you can see it calls exec.Command with a list of variable args instead of a pre-assembled string:

https://github.com/coreybutler/nvm-windows/blob/256d69427b501b673057d11f59aeca073934ba87/src/nvm.go#L444

Since I don't quite know the intent of the runElevated method and it clearly works for almost all the other times it's called, I figured it made more sense to avoid changing that. So I walked back up the call stack to where the use method tries to actually create the symlink and patch it there. I ended up with this change starting at around line 562 here: https://github.com/coreybutler/nvm-windows/blob/5803c4f8c7766c670996fbce3fc113a9b0d95050/src/nvm.go#L562

ok, err = runElevated(fmt.Sprintf(`"%s" cmd /C mklink /D "%s" "%s"`, filepath.Join(env.root, "elevate.cmd"), filepath.Clean(env.symlink), filepath.Join(env.root, "v"+version)))
	if err != nil {
		if strings.Contains(err.Error(), "not have sufficient privilege") {
			cmd := exec.Command(filepath.Join(env.root, "elevate.cmd"), "cmd", "/C", "mklink", "/D", filepath.Clean(env.symlink), filepath.Join(env.root, "v"+version))
			var output bytes.Buffer
			var _stderr bytes.Buffer
			cmd.Stdout = &output
			cmd.Stderr = &_stderr
			perr := cmd.Run()
			if perr != nil {
				ok = false
				fmt.Println(fmt.Sprint(perr) + ": " + _stderr.String())
			} else {
				ok = true
			}
		} else if strings.Contains(err.Error(), "file already exists") {
			ok, err = runElevated(fmt.Sprintf(`"%s" cmd /C rmdir "%s"`, filepath.Join(env.root, "elevate.cmd"), filepath.Clean(env.symlink)))

This seemed to generate the UAC prompt and update the symlink appropriately. I don't think this perfectly captures every error case - if the "file already exists" for example it may not behave quite right or something. I didn't actually ever see that happen in my testing though.

I did notice that as a result I could set an "admin" version and a standard user version distinctly. That is, from an admin prompt, nvm use couldn't influence what nvm use had set for a standard user and vice-versa. This was a little surprising. I'm not sure if the 1.1.7 version currently behaves like that.

I don't really know if this is a good solution or not. I'm gonna stop here but am curious if anyone has any feedback for me. If not, at least I learned some Go.

[1011025m]

To add onto this, the error message that this gives has an encoding error (error in an error lol) if you don't use English as the system language. Minor issue, but you know what I mean

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[ViliusS]

ping

[WORMSS]

1. Uninstalled nvm completely, confirmed by finding zero %appdata%/.nvm folder

2. Installed fresh copy of 1.1.9 from Github

3. opened a new CMD window. (Not admin)

C:\WINDOWS\system32>nvm version
1.1.9

C:\WINDOWS\system32>nvm install latest
Downloading node.js version 18.0.0 (64-bit)...
Extracting...
Complete

Installation complete. If you want to use this version, type

nvm use 18.0.0

C:\WINDOWS\system32>nvm use 18.0.0
exit status 1: Access is denied.

C:\WINDOWS\system32>nvm uninstall 18.0.0
Uninstalling node v18.0.0... done

4. Uninstalled nvm completely, confirmed by finding zero %appdata%/.nvm folder

5. Installed 1.1.7

6. Opened a new CMD window. (Not admin)

C:\WINDOWS\system32>nvm version
1.1.7

C:\WINDOWS\system32>nvm install latest
Downloading node.js version 18.0.0 (64-bit)...
Complete
Creating C:\Users\CRichardson\AppData\Roaming\nvm\temp

Downloading npm version 8.6.0... Complete
Installing npm v8.6.0...

Installation complete. If you want to use this version, type

nvm use 18.0.0

C:\WINDOWS\system32>nvm use 18.0.0
Now using node v18.0.0 (64-bit)

C:\WINDOWS\system32>node --version
v18.0.0

So, the problem between 1.1.7 and later versions is still happening.