Start ShareX as correct user after upgrade

[tobbez]

Currently, it's started as administrator after an upgrade has finished, making some things not work, like for example saving screenshots to a network drive (since it's only mounted under the regular user account).

It would be good if it could be started as the user account under which the pre-upgrade instance of ShareX was running.

[Jaex]

Because installer must run as admin, installer unable to run ShareX as non admin.

[tobbez]

Many other installers seem to have solved this very same issue, somehow.

For example, if using a WiX based installer, the Impersonate property allows to do exactly this[1].

Even if you use something other than WiX for creating the installer, there should be something that provides the same functionality.

[1] http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/run_program_after_install.html

[Jaex]

I'm using InnoSetup.

[tobbez]

Looking a bit closer, it seems that the problem is not with how the installer is configured, but with how it is launched by ShareX during an upgrade.

The problem does not occur upon initial installation, only when upgrading, which means it happens because of how it is launched.

The InnoSetup documentation confirms that it should currently work, since the postinstall flag turns on impersonation (i.e. running the program as the original user) by default.

Although I may be wrong, I think it is because the Verb of the ProcessStartInfo is set to runas, which causes the process to already be running as Adminstrator when starting, rather than starting it as the current user, and then letting windows elevate the process.

This means that impersonation can not work, because the installer has no way of knowing which the original user was.

[Jaex]

I think I was added runas after few people reported they were having issues updating. So if I remove it now other people can open issue telling it is causing problem.

[tobbez]

Do you remember where the issues for those problems are?

I checked the git logs, but it appears this change was introduced before you moved to git, and you didn't import the subversion history when migrating.

[Jaex]

It was long years ago so I don't remember where it is now. And from that day nobody told anything about updating because it was working fine for everybody after add runas.

[tobbez]

Except it's not fully working. You just won't notice it in the most common use cases.

Network drives not working after upgrading (without restarting) is one example, but I don't think saving new settings will work properly either, unless you restart.

[Jaex]

Removed runas, hopefully it won't create issue to people.

[Jaex]

Now many people started to report admin run is required :( I knew this would happen when I remove it.

[tobbez]

It looks like that's because of an additional problem - for some reason, PrivilegesRequired[1] is set to none rather than the default value of admin in ShareX-setup.iss[2]. Setting it to admin should make the installer process properly elevate itself (and ask for credentials if required).

1: http://www.jrsoftware.org/ishelp/index.php?topic=setup_privilegesrequired 2: https://github.com/ShareX/ShareX/blob/master/ShareX.Setup/InnoSetup/ShareX-setup.iss#L33

[Jaex]

When I add admin to setup then people don't have admin access can't install it to outside program files.

[tobbez]

Alright, here's all the options I've come up with:

1. Revert the removal of runas. This would (still) have the problem of leaving the updated ShareX instance running elevated rather than as the user the previous version was launched as when updating.
2. Keep it as it is now. Problematic since it breaks upgrades for non-admin users (as in #1399).
3. Make the installer re-launch itself with elevated privileges if it can't write to the destination directory. This still has the same issue as number one though.
4. Add a small utility that when upgrading starts the installer, waits for it to finish, and then relaunches ShareX.
5. Switch from Inno Setup to WiX, which seems to have support[1] for dual-purpose install packages, where the user gets to choose whether program gets installed for everyone or just the current user.

Option five looks like the best solution to me, but it's also the one that takes most work, and you would have to make sure that upgrades from installations made using previous installers to new one works.

Option four also solves all the issues, but at the cost of some complexity, plus the need for an extra executable.

Option three adds extra complexity, but still has the same problem as using runas when launching the installer.

1: See InstallScopeDlg on http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_dialogs.html

[Jaex]

I'm not planning to change setup script it will be alot of efforts, especially handling updating because first need to detect which installer used then uninstall it then install using new installer etc. so many complexity and possibility of something can go wrong because how ShareX can do these while its uninstalling etc.

[JasonMayeaux]

Ah, so this is why my screenshots were saving to the Administrator documents folder instead of mine...

[Muramas]

You could get around this by just installing into Appdata. Google chrome does this when the user does not have admin access.

C:\Users\UserName\AppData\Local\ShareX\

This will also remove the stupid admin access for updates issue

---

Requires Admin rights

• Installing to system-level directories.
• Program Files, Program Files (x86), Windows
• Modifying system-wide registry entries under HKEY_LOCAL_MACHINE
• Installing device drivers
• Installing ActiveX controls
• Configuring Windows Updates
• Viewing or changing another user's folders or files

Does not require Admin rights

• Installing to user-level directories
• AppData, LocalAppData, Desktop
• Modifying HKEY_CURRENT_USER in Registry

[jdgregson]

Shame that this isn't being taken more seriously as it is a significant issue. At the very least I prefer that ShareX not be started at all after an update, so that I can start it myself with my own account.

[Jaex]

Shame that this isn't being taken more seriously as it is a significant issue.

Just because I'm unable to fix it means I'm not taking it seriously? Do you think if I could fix it that I wouldn't?

[Muramas]

I'm not planning to change setup script it will be alot of efforts, especially handling updating because first need to detect which installer used then uninstall it then install using new installer etc. so many complexity and possibility of something can go wrong because how ShareX can do these while its uninstalling etc.

You clearly state that it is possible and not that you are "unable" to fix. If this packager isn't working switch to a different installer.

[Jaex]

It is just that easy, switch whole installer. Do you have any idea how much problems it can create switching installer or lack of features that new installer can have. Of course you won't care as long as it fixes your problem. When I wrote I'm unable to fix it I obviously implied by using current installer.

[jdgregson]

@Jaex I apologize for saying that you don't take it seriously, you obviously do. What I should have said is that the project as a whole isn't taking this issue seriously enough if it has been going on for more than 3 years.

Starting the application as an administrator after installation means that, if the user changes application settings, they're likely changing settings for another account and will have to change them again after they restart.

Starting the application as an administrator after installation means that, after an update, users will likely be met with a feeling of rage when they realize that their carefully crafted settings have seemingly been wiped away, since they're running the application as the administrative user.

I have seen some other applications that start as an admin after installation, but it's never good, useful, intuitive, or beneficial to do that.

At the very least, this issue should be closed as wontfix rather than cantfix, since you've previously indicated that you can fix it but choose not to.

[Jaex]

By the way ShareX auto updater only runs installer as admin if ShareX was installed to program files. If you install ShareX outside of program files, for example to AppData folder then ShareX won't run installer as admin. That way after installation is complete, ShareX will auto run as current user.

[Jaex]

@QuadPiece related to issue #1399, is in initial installation were you running setup file as administrator yourself or setup automatically ask for it? Because I needed to revert my changes about not running installer as admin in auto updater, that means you must have run installer as admin manually to install ShareX initially.

In InnoSetup script we are using none value for PrivilegesRequired option.

Because if admin is used then users won't be able to install ShareX to location where admin permission is not required at all.

When set to none, Setup will only run with administrative privileges if it was started by a member of the Administrators group. Do not use this setting unless you are sure your installation will run successfully on unprivileged accounts.

So for normal users they are member of the administrators group therefore they can just run setup and it will show UAC dialog automatically. But for you it did not show therefore needed to run installer as administrator.

So as workaround I was thinking of checking if your user account is not member of the administrators group, only then running installer as admin.

Like this:

That way for normal users installer won't be run as admin, but installer will ask for it automatically and then ShareX can be run as non admin after installation is complete. But only for special cases like yours, installer will be run as admin.

But I need to test this code and need your help for testing it to make sure it works in your case.

[Muramas]

As a suggestion, after seeing how installer works for other apps like Discord and Microsoft teams, I would suggest looking into the Squirrel installer.

-Installing is Wizard-Free™, with no UAC dialogs, does not require reboot, and is .NET Framework friendly. -Updating is in the background, doesn't interrupt the user, and does not require a reboot.

https://github.com/Squirrel/Squirrel.Windows

https://intellitect.com/deploying-app-squirrel/