Allow /ascurrentuser option to cobiaRegister on Windows

[jasper]

COBIA stub code will refuse to load COBIA runtime installed by a current user from an elevated process. This is a security measure to counter a possible DLL hijack by a current user replacing COBIA.dll or one of its dependencies.

Some installers elevate in a mixed-mode scenario even when installing for the current user. Particularly the default multi-user scenario of NSIS is subject to this.

This scenario in which COBIA is being installed for the current user, and the PMC registration is executed elevated, the PMC registration fails, as COBIA cannot be loaded.

Workaround is to provide a /ascurrentuser option to cobiaRegister that, in case it is started with elevated rights, will restart itself with the same command line options, impersonating the unelevated current user.

This option is to be specified by installers that run a current user installation mode with admin rights (elevated)

[jasper]

The /ascurrentuser scenario is not straight forward. This solution

​https://devblogs.microsoft.com/oldnewthing/20190425-00/?p=102443

fails as soon as it is attempted to pipe the output, handles cannot be inherited. The solution via CreateProcessAsUser? / GetSaferToken? actually creates a process that is still elevated (solution documented here: ​https://stackoverflow.com/questions/17765568/how-to-start-a-process-unelevated, scroll down to the accepted solution); here's a wider discussion about the whole topic, ​https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/20a2d22b-6de6-449a-82f8-6b17e6ccd5be/how-to-createprocess-not-as-administrator?forum=windowssecurity

I would say none of this accomplishes what we want to do in a safe manner, and we should give up on this strategy.

Which brings us back to the following options:

• we allow somehow (command line options, ...) an elevated process to start a per-user installed COBIA runtime. I still advise strongly against this as it opens a path to a DLL hijack scenario

• we put out an advisory simply that one should not attempt a current user PMC registration from an elevated process, and leave any NSIS mixed mode installation issues a problem to be solved by the software vendor. This is not an unfair solution - the whole thing really starts from NSIS elevating for a current user installation, which it should not

• another option we could consider is allow a route where we manipulate the current registry without loading the COBIA middleware (so: not using the registrar). This route is of course fraught with maintenance issues, risks of breaking the registry, etc

• yet another route is that we make a version of the registration tool that loads a specific version of COBIA that is bundled with the installer, just for registration purpuses. A bit more difficult to pack, but in principle safe, as a DLL that comes with the installer cannot be hijacked easily.

Personally the simplest and cleanest solution is to just disallow it. Work-arounds for NSIS users that want a dual mode installation include:

• do not tell the NSIS installer to run at priority level Highest. Instead (a) run as user by default, (b) if somebody wants to install for all users, the installer must explicitly be started "As Administrator", (c) make sure to check at starting the installion tasks that the elevation status of the process matches the current user or all users option (in both directions, cannot register for all users as current user eithre). To get this to compile, the NSIS header will complain unless you define MULTIUSER_EXECUTIONLEVEL_ALLUSERS.

• use the boot-strap approach - stick an unelevated executable around the NSIS installer that launches the NSIS installer (which will elevate), and depending on the outcome of the install, run the current user registration from the unelevated bootstrap process after the installer has finished.

[michelpons]

Going for solution "we put out an advisory simply that one should not attempt a current user PMC registration from an elevated process, and leave any NSIS mixed mode installation issues a problem to be solved by the software vendor. This is not an unfair solution - the whole thing really starts from NSIS elevating for a current user installation, which it should not ".
However the issue with NSIS should then be properly documented (I have not seen in the above a reference in any blog).
I agree that CO-LaN is not responsible for issues in third-party software. If CO-LaN could easily resolve that issue, CO-LaN would do it, but solution is, at best, overly complex to implement. Moving to 'won't fix' once additional references are provided should be sufficient and would leave software vendors with the opportunity to dig into the issue further.

[jasper]

Here's a reference that allows one to implement the 'bootstrap' solution in NSIS:

​https://nsis.sourceforge.io/UAC_plug-in

Except it is deprecated. There are plenty of posts on the subject, here's one:

​https://nsis-dev.github.io/NSIS-Forums/html/t-292340.html

no modern solutions though - the bootstrap solution seems reasonable.

[jasper]

So if we are closing this one as won't-fix - let's move forward and release 1.2.0.9?