Repository navigation
Sources don't update if something that would update the sources (winget show, for example) is run from an elevated CMD window in an account that's not in the Administrators group. #528
Description
Brief description of your issue
Doing something that updates winget's sources from an elevated CMD/PowerShell window while logged into a user account that's not in the Administrators group doesn't actually update the sources.
Steps to reproduce
Note: winget will need to be installed in both accounts. Installing it in the account that's in the Administrators group will ask you to re-install, but in reality it's not installed in that account yet. winget may also complain about sources being broken after re-installing and trying to run from the account that's not in the Administrators group, but I haven't noticed this while verifying this issue.
Note 2: There will need to be a "Standard" account (according to what the Windows 10 Settings app calls accounts not in the Administrators group) in addition to an account with Administrator permissions, which is being referred to here as "Admin" to make it shorter.
- Open an elevated CMD/PowerShell window from the account that's not in the Administrators group.
- Run
winget show > (a text file somewhere that you'll check later) - Open a non-elevated CMD/PowerShell window from the same account.
- Run
winget show > (a text file with a different name from the earlier one; you'll check this one later, too). - Compare the two text files and notice that the progress bar goes from 0% to 100% in the elevated prompt output, while it gradually increases as expected in the non-elevated prompt output. An example is pasted in the "Actual behavior" section.
Reproduction steps were changed to use ones that may be more easily reproducible.
Expected behavior
The sources should be updated just like they would be if you used a non-elevated CMD/PowerShell window.
Actual behavior
Sources don't actually update even though winget says they were updated. If you do something that updates the sources in a non-elevated window (winget show, for example) then try to do the same thing in the elevated window, it acts as if the sources were updated, even though they weren't updated in the elevated window.
I ran winget show first in the elevated prompt first and directly afterward ran it in the non-elevated prompt, and sent its output to a text file both times. Since it keeps the progress bar in the output, I've pasted them here:
Elevated:
██████████████████████████████ 383 KB / 383 KB
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%
██████████████████████████████ 383 KB / 383 KB
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%
Non-elevated run directly after the elevated one:
██████████████████████████████ 383 KB / 383 KB
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 1%
█▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 4%
█▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 5%
█▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 6%
██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 7%
██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 9%
███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 10%
███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 12%
███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 13%
████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 14%
████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 16%
█████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 18%
██████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 23%
█████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 44%
███████████████████████▒▒▒▒▒▒▒ 77%
███████████████████████▒▒▒▒▒▒▒ 77%
███████████████████████▒▒▒▒▒▒▒ 78%
██████████████████████████████ 100%
Environment
[winget --info]
Windows Package Manager v0.1.42101 Preview
Windows: Windows.Desktopv10.0.18362.959
Package: Microsoft.DesktopAppInstaller v1.10.42101.0
Any other software? None relevant to this issue.
This was verified in winget v0.1.42101 on my primary desktop.
Activity
megamorf commentedon Aug 6, 2020
You don't actually need to update sources manually. That's being done behind the scenes after the cache has gone stale.
https://github.com/microsoft/winget-cli/blob/master/doc/Settings.md#autoupdateintervalinminutes
DrewNaylor commentedon Aug 6, 2020
I'm aware of that, but unless it updates for the Admin account at the same time as the standard account, running
winget show (package)as admin didn't update the cache for me even though the cache-updating progress bar showed up.megamorf commentedon Aug 6, 2020
As for the account issue. If you're running winget with a user that is not member of the Administrators group then that behaviour is expected.
When a user account that is member of the Administrators group logs on, the Explorer and other processes will be started with a standard user access token. That user can then run a process elevated via UAC which grants that process an additional full administrative access token. Both belong to the same user and therefore same user profile.
What you have is a user that is not a member of the Administrators group. That means that user cannot elevate processes. In this case UAC allows you to use another user account that is member of the Administrators group to run that process. In this case you're actually executing a process in the context of a different user and therefore user profile. That means the paths where that foreign process writes to is different from your non-admin user and there is no way of solving this. That's by design
DrewNaylor commentedon Aug 6, 2020
That makes sense, but the issue is that winget isn't updating the cache when I'm running it elevated from a regular account, while it does update when not running it elevated from the same regular account.
megamorf commentedon Aug 7, 2020
You really need to be more specific with your statements and re-read my comment that explains how UAC works.
DrewNaylor commentedon Aug 7, 2020
What I'm trying to say is, the elevated prompt in a standard account isn't updating the cache in the account the elevated prompt is using, while the non-elevated prompt is updating the cache in both the elevated and non-elevated prompts. I re-read the earlier comment more thoroughly and understand that part.
megamorf commentedon Aug 7, 2020
Please refrain from using the term "standard account" or "regular account" - there is no such thing. Your user account is either member of the Administrators group (default) or it isn't (either deliberate choice or corporate policy). The former can elevate its own processes whereas the latter needs another user account to do that.
From what I understood your scenario is the latter where you use an account with limited permissions (not member of Administrators group) and elevate CMD with a different user account that is member of the Administrators group. Is that correct?
You can run the command
whoami /groupsto clarify that.DrewNaylor commentedon Aug 7, 2020
That is correct. Sorry, I was just going off what Windows 10 calls accounts in the account settings section of the Settings app.
Decided to send
winget show's out put to a text file from both the elevated and non-elevated prompts, and it includes the progress bar when it updates its cache, so I'll edit the first post with them if it helps this issue.[-]Sources don't update if "winget source update" is run from an Admin CMD window in a "Standard" user account.[/-][+]Sources don't update if "winget source update" is run from an elevated CMD window in an account that's not in the Administrators group.[/+][-]Sources don't update if "winget source update" is run from an elevated CMD window in an account that's not in the Administrators group.[/-][+]Sources don't update if something that would update the sources (winget show, for example) is run from an elevated CMD window in an account that's not in the Administrators group.[/+]megamorf commentedon Aug 8, 2020
After clarifying your setup the problem is indeed not with elevated permissions (CMD and its child processes having the administrative user token) but that you're simply using winget with two different user accounts.
That behaviour is expected. Here's a more detailed explanation why:
Say we have two Windows user accounts:
Administrators)When I print
LimitedUserpath variables in PowerShell it gives:Now as
LimitedUserI want to run PowerShell elevated. A UAC prompt shows up allowing me to run the process asNormalUser. When I run the same commands the output is different:Winget writes to
%LocalAppData%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe. That means that depending on whether you ran winget in the first or second example its filesystem interaction was with different user profiles.There's nothing to fix here - this is by design. Regardless of Windows version the user profile is considered an access boundary. This applies to all processes, e.g. an MSI setup will always write to %TEMP% and applied to your scenario you wouldn't find its files in
C:\Users\LimitedUser\AppData\Local\Tempbut underC:\Users\NormalUser\AppData\Local\Temp.DrewNaylor commentedon Aug 9, 2020
This makes sense regarding file access. Just strange that the progress bar behaves differently when run elevated from a user not in the Administrators group compared to running non-elevated from the same user.
denelon commentedon Aug 10, 2020
Drew Naylor (@DrewNaylor), I will dig in a bit deeper to try and clarify exactly what is happening.
denelon commentedon Aug 10, 2020
I believe Sebastian N. (@megamorf) correctly described the account specific behavior. This looks like an edge case where there were multiple instances of installation for the client. The TTL value is stored based on the installed user(s). Each installed location has it's own reference timestamp for the TTL calculation. I expect the undesired behavior is being network inefficient primarily. We're looking at Delivery Optimization and being Metered Network aware in the backlog. I'm going to reference #151 as a signal to look back at this Issue. The fix for this would likely require some additional engineering to minimize the additional unnecessary downloads for the cache.