rpi-imager
rpi-imager copied to clipboard
raspberrypi
[BUG] Windows install as a non-admin user doesn't install for that user
[Win 11 x64] If I run the Windows installer as a non-admin user then I correctly get prompted for admin user / pw and the software installs. Unfortunately it only installs for the admin user I just selected to get install privs. It should, at least, install for my original user and maybe offer a "install for all" / "install for current user only" option?
@jc-kynesim Unfortunately, I can't clearly understand what your expectation is here - I'd suggest against deleting the template for future issues.
My best guess is you want to be able to install as a non-administrator user, but I'm not sure what you hope to gain from that. Writing images on Windows requires Administrator rights, so allowing non-Admin installs would create a situation where the Raspberry Pi Imager is broken from install.
Have I read your report correctly?
Yes I want to be able to install & use imager from a non-admin user. Yes I expect to be asked for admin credentials on install for all users & at the point where the code requires them to write to SD (though if you installed just for the current user you might not need install credentials). I don't want to have to switch user just to write an SD card. Balena works as I expect. As it stands I get asked for admin credentials on install, the install proceeds and then my current user cannot see the application - this is confusing. I think imager is pretty the only program that I have ever installed on Windows that doesn't install as I expect above.
@jc-kynesim I'm not inclined to address this in the near term, in part because I'm not sure I believe this is a common Windows operating model.
Typical Home Windows installs have been (at least as long as I've been using PCs) set up where the primary home user has the Administrator role. Microsoft effectively built their security model around this - UAC et al.
In models where a user has not been granted the Administrator role, that is typically because they are not trusted to make modifications to the system - for example raw disk access. This set up is fairly common in corporate or education environments (eg Universities).
The defining feature of that model, however, is that those roles do not have Administrator access.
You've described something different - a model where you want a user that deliberately has not been granted the Administrator role to be able to perform actions the Windows model would expect only an Administrator to perform. That user also apparently has Administrator credentials, and could presumably grant themselves the role if they opted to. In >20 years of working (and playing) with Windows, I've never come across this as an expected case.
As such, without more reports of this particular problem, I can't give it priority. One thing you might consider doing is removing Windows from the equation entirely - using a USB drive or similar to boot Raspberry Pi OS, and run Imager from that environment to write SD cards - which would also allow someone else to use your PC uninterrupted.
Just as a point of comparison, Balena Etcher suffers from a similar problem to this on MacOS X - see https://github.com/balena-io/etcher/issues/3798 and https://github.com/balena-io/etcher/issues/3321
Microsoft's guidelines explicitly say that installers, when performing a system-wide install, should not install anything per-user. Not sure what this installer is doing exactly but it should really only be installing everything system-wide (so all users can use it.)
I can't find the exact doc from Microsoft but this one seems close enough: https://learn.microsoft.com/en-us/windows/win32/win_cert/certification-requirements-for-windows-desktop-apps
10.6 Your app must write user data at first run and not during the installation in per-machine installations When the app is installed, there is no correct user location in which to store data.
Microsoft's guidelines explicitly say that installers, when performing a system-wide install, should not install anything per-user. Not sure what this installer is doing exactly but it should really only be installing everything system-wide (so all users can use it.)
I can't find the exact doc from Microsoft but this one seems close enough: https://learn.microsoft.com/en-us/windows/win32/win_cert/certification-requirements-for-windows-desktop-apps
10.6 Your app must write user data at first run and not during the installation in per-machine installations When the app is installed, there is no correct user location in which to store data.
Those guidelines do not apply if you are not seeking Windows certification - which we are not. I can see no advantage to our users of doing so at this time. As the OP pointed out, this is installing per user and requiring Administrator rights to do so -
As stated above, there isn't the imperative to address this before 2.0 - and even then, I don't see how aiming for Windows certification would address this concern, given there is an exemption from UAC behaviours for tools that are:
Administrative or system tools with execution level set to highestAvailable, and/or requireAdministrator
And rpi-imager has requireAdministrator set.
Those guidelines do not apply if you are not seeking Windows certification - which we are not. I can see no advantage to our users of doing so at this time. As the OP pointed out, this is installing per user and requiring Administrator rights to do so -
As stated above, there isn't the imperative to address this before 2.0 - and even then, I don't see how aiming for Windows certification would address this concern, given there is an exemption from UAC behaviours for tools that are:
I did not mention "certification" anywhere in my message, and certainly the intent wasn't to say that you should get certified in any way. I did admit already that the link I posted wasn't the best source, because ultimately these guidelines are just best practices, certification or not.
Anyway, the current installer seems to have been auto-generated at some point, and has plenty of minor issues like this one to fix. I can do that and create a pull request for that, if you're interested. (I have done this sort of thing previously.)
To be clear, what the fix would achieve is:
- Either just install properly for all users, since we're elevating anyway; (this would be my preferred approach.)
- Or, present an option for installing for the current user only, although running it would still require elevation -- but at least the shortcuts etc. would be in the right place.