Why is WixSharp_BeforeInstall_Action an immediate CustomAction (and not deferred)?

[coderafk]

Hello @oleg-shilo,

we would like to move our CustomActions to the event functions (Load, BeforeInstall, AfterInstall) to simplify our source code.

Unfortunately, this is not possible for certain actions that need to be executed before InstallFiles (in WixSharp_BeforeInstall_Action) because they need to run with elevated privileges.

WixSharp_BeforeInstall_Action is an immediate CustomAction and therefore functions with elevated rights cannot be executed.

The reason WixSharp_BeforeInstall_Action is an immediate CustomAction is that it requires the session object to customize the ADDFEATURES property. But in my opinion, this should be a completely separate CustomAction.

My understanding is that immediate actions executed between InstallInitialize InstallFinalize should only be used to customize the execution script.

WixSharp_AfterInstall_Action is a deferred CustomAction and so it is possible to execute different things with system rights.

We do not want to recommend the user to open a command shell as administrator every time and then perform the installation with msiexec.

"project.InstallPrivileges = InstallPrivileges.elevated;" is set.

What is your opinion on this?

Kind regards

Frank

[oleg-shilo]

Hi Frank,

Thank you for such an insightful feedback.

I actually agree with all your points. But I am not sure that making an additional elevated WixSharp_BeforeInstall_Action event is the best option.

The reasons for this is not technical but rather API design-related. The initial rationale was to make all events immediate as the users almost always want to have access to the session properties (deferred actions are limited with that). Timing is also critical as often user wants to execute the action run right away. The only exception is the AfterInstall event: timing is not important (the session is over) and the need for elevation is more probable. And yet.... I had to implement project.UnelevateAfterInstallEvent(); upon specific user request. Some did not like elevation :)

Thus to satisfy your use case by updating WixSharp API I have the following options:

1. Split WixSharp_BeforeInstall_Action in two instances (your proposal)
   Impact: current users who already rely on this event and will be impacted.
2. Split WixSharp_BeforeInstall_Action in two instances elevated and unelevated (current) and expose them both
   Impact: I may be requested to do the same for all three events.
3. Implement project.ElevateBeforeInstallEvent(); it simply changes the CA to deferred onfly. You can do it currently with project.WixSourceGenerated manipulation.
   Impact: I need to introduce a private extra WixSharp_BeforeInstall_Action to deal with ADDFEATURES property for custom UI.

I am leaning towards #3. You?

[oleg-shilo]

I think I have to find another option because being deferred is not a reliable mechanism for elevation. See #1567

I have an idea how to do that. All good

[coderafk]

Hello @oleg-shilo,

Thank you for your quick reply and I'm looking forward to the solution. :-) Would you like to share your idea with me?

It's nice that you have once again pointed out the implications of the different approaches.

3) Can you please explain exactly how you would like to implement this?

WixSharp_BeforeInstall_Action wants to change the session object (change of ADDFEATURE) and this is not possible as a deferred CA.

I understand that timing is important for users, but that's why you created WixSharp_Load_Action. This event is unelevated, has access to the session object and can make any preparations for the execution script. The time before InstallInitialize could possibly be relevant, but I haven't found a use case for that yet.

But I can't think of a practical situation where a user would need an event to change the execution script while the execution script is being created. This is really very special, I think.

I understand that WixSharp_BeforeInstall_Action can't suddenly be elevated. So at the moment I actually think only an additional CA e.g. WixSharp_BeforeInstall_Action_Elevated could be a solution.

And something else. I'm really impressed by how many years you've been supporting this project. Thank you very much for everything. If you should ever be in Hamburg or anywhere in Germany, please write beforehand. Then we can talk about our projects if you like.

Best regards

Frank

[coderafk]

Hello @oleg-shilo ,

I have now understood version 3. Basically this could work, but it feels like a workaround for something that is not intended in MSI.

I understand it like this:

1.) InstallScope.perUser (then InstallPrivileges must be limited)
Any deferred CustomAction between InstallInitialize and InstallFinalize is not elevated because it runs in the context of the user.
Such setups can be used if files are copied to the user's directories or only changes to HKCU are necessary.

2.) InstallScope.perMachine (then InstallPrivileges must be elevated)
Every deferred CustomAction between InstallInitialize and InstallFinalize is elevated because it runs in the context of LocalSystem. Such CustomActions can be impersonated, but are then executed with elevated privileges.
Such setups can be used when programs are installed and changes to HKLM are also necessary.

Note: WixSharp_BeforeInstall_Action is only executed with non-elevated rights under InstallScope.perMachine because it is executed as immediate, which was actually intended to change the execution script, but not to make any changes to the system.

If a developer wants to execute files with non-elevated rights, she\he must create the MSI as InstallScope.perUser.

How do you see this?

Best Frank

[oleg-shilo]

a workaround for something that is not intended in MSI.

You are spot on. This is exactly what it is.
Though... this does not invalidate the approach. MSI was released 25 years ago. It does not support so many things that are required today (e.g. elevation). And has so many awkward architectural elements that look ridiculous today (custom actions and dialogs being executed in a separate process). Some later changes are equally awkward (e.g. scheduling and elevation being completely coupled via deferred actions in perMachine scenario).

Today, users often implement unorthodox scenarios. Just to illustrate this, a user may perform per-uesr installation that requires admin action in the middle of install. IE access to the licence store with the admin rights. It is a valid scenario in cases when the setup is performed by an admin but in the user profile.

I am currently working on #1567 and I have succeeded with the most difficult task of marshalling session to the external process so it looks promising.

When it's all done the all events will have Execute.Immediate (including AfterInstall) and will be executed within the msi InstallScope.
Additionally, you will be able to request the event execution in a separate elevated process while still being Execute.Immediate.

This way the elevation is completely decoupled from scheduling (being deferred) and InstallScope (even the non-admin user may request admin tasks). While still being secure. The OS will still ask credentials before performing the elevation.

By default, all events except AfterInstall will be unelevated.

[coderafk]

Hello @oleg-shilo ,

thank you very much for the explanation. I see it the same way. And why is MSI still used so often? The answer also lies with Microsoft. Software distribution via Active Directory can only be done with MSI packages. This means that every medium-sized company that cannot or does not want to purchase any other software distribution system is dependent on MSI packages.

I am already looking forward to the new solution.

Many thanks Frank

[coderafk]

Hello @oleg-shilo,

we just noticed that e.g. WixSharp_AfterInstall_Action has to be impersonate for us to make changes to HKCU. I don't know if this is necessary for every task in WixSharp_AfterInstall_Action and if there are also tasks where it must not be impersonate. How do we want to handle this in the future? Do we perhaps even need two WixSharp_AfterInstall_Action (impersonate and not impersonate?)?

What do you think?

Best regards Frank

[oleg-shilo]

Good news. The model I described is working and now I have done the whole roundtrip for even elevation. It works just fine.
Now I need to wrap it all up in a nice API and release it when it's done.

It was a scary moment when I thought that I hit the wall on the very last step. I built an event elevation executable (see here) with a proper manifest stamped with the elevation request. I signed the executable assembly. Tested it locally, without embedding it to msi.
And .... when this executable is run from the msi session Windows Defender decides that it is a virus and kills the msi session. Thank God the old-fashioned "runas" works just fine.

[oleg-shilo]

Done. The latest release v2.2.0 allows controlling the hosting environment of the managed events (custom actions).
You can now specify the execution model for all three MSI events. You can schedule the events as immediate, deferred or executed in an elevated external process (for cases when deferred actions are still not elevated because of the InstallScopePerUser).

project.BeforeInstallEventExecution = EventExecution.MsiSessionScopeImmediate; 
project.BeforeInstallEventExecution = EventExecution.MsiSessionScopeDeferred;
project.BeforeInstallEventExecution = EventExecution.ExternalElevatedProcess;

// the same for Load and AfterInstall events

This is the code sample in the repository: https://github.com/oleg-shilo/wixsharp/blob/wix-v4-master/Source/src/WixSharp.Samples/Wix%23%20Samples/InstallEventElevation/setup.cs