[wix-users] EXT: Re: Running BA elevated

Mon Oct 28 10:41:10 PDT 2019

I will research how to get the engine to perform a query for me, that sounds like something useful, except that the user will get a UAC message halfway through the UI, but that’s better than the alternative.

Thanks.

From: Edwin Castro <egcastr at gmail.com>
Sent: Monday, October 28, 2019 11:44 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com>; Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: EXT: Re: [wix-users] Running BA elevated

Rephrasing what Jacob is saying just a tiny bit, the UI/BA should communicate with the engine so that the engine can elevate, ask the question, then pass the results back to the UI/BA. This is the proper, targeted solution for a situation where you are performing a query that Windows requires to be elevated.

Elevating the entire process for this purpose is like using a nuclear bomb when a hammer, or perhaps a hatchet, would do. Sure it is easier to blow it all up but you've also lost the ability to perform more targeted, controlled, surgical actions.

This is the principle of least privilege and the Windows Installer itself also follows this model because it is categorically better than reducing security for the entire process when it is not needed. If your UI was just a Windows Installer UI you'd have the same problem there, with likely less options for a workaround because getting Microsoft to add that capability would be quite difficult, if not impossible. The WiX Burn engine is something the WiX community can control but that doesn't mean all changes should be made without careful consideration. Sometimes, "easy" really is not the right solution.

--
Edwin G. Castro

On Mon, Oct 28, 2019 at 9:27 AM Hoover, Jacob via wix-users <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>> wrote:
The exe is not the engine...  They are 2 separate entities within the exe.  Your UI is the BA, and it should NEVER have elevated permissions.  The engine on the other hand, for a per machine install will elevate and handle the machine state modifications.

If you would like to join a wix-dev's session and plead your case, or reach out to FrieGiant and see if they have a BA/Engine which can accommodate your needs, feel free to do so.  But as it stands, the codebase is designed explicitly to prevent you from doing what you are attempting to do.  This is because it's a slippery slope and once the BA/UX has admin, it's always easier to hack in changes there as opposed to well thought out authoring which handles all the different install/update/rollback/patch/remove states, and failures when attempting to transition between them.

Again, I don't mean to sound terse or pretentious but what you are trying to do is cutting against the grain of how the codebase was designed.

-----Original Message-----
From: Vanniekerk, Tyrel (GE Healthcare) [mailto:tyrel.vanniekerk at ge.com<mailto:tyrel.vanniekerk at ge.com>]
Sent: Monday, October 28, 2019 11:02 AM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
Subject: RE: Running BA elevated

Hi,

Not sure I agree that it's a hack to allow the engine to run elevated.  The case where the installer needs to read some information from the system that requires elevated permissions makes it impossible to perform that action in the UI if you don't allow the BA to elevate.

I suppose what I am saying is that there's a difference between saying it's good or preferred not to do something and making it a law.  If it's a suggestion, then the person creating the installer can choose to override that suggestion, but as it is now, we have to force some hack to provide what our company is asking us to do.

The requirement is that the UI should ask for a password and ensure it conforms to the machine's policies, a simple request, but not possible without a hack.

So the hack for me is getting around a design constraint rather than providing an option to override the constraint.

Sorry, I don't mean to sound argumentative or anything, I just prefer not to have to write bad code to get around something that could easily be provided.  The documentation could provide a good explanation why it's bad to override that option, but let the user get on his merry way if he chooses to ignore the warning.

Thanks,
Tyrel

-----Original Message-----
From: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>>
Sent: Monday, October 28, 2019 10:04 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com<mailto:tyrel.vanniekerk at ge.com>>
Subject: EXT: RE: Running BA elevated

BA's don't modify machine state, installers and in controlled conditions the engine does (for ARP, autorun, etc).

Normal flow, you have a complete plan in place with rollback plans for the bundle before elevating. For some situations, you may have found some fringe cases where you might need elevation prior to this, but the proper answer is probably going to be to submit a WIP to teach the engine the ability to elevate early when this info is requested.  It is a hack to just say, give my UI Admin because it's hard to make the engine request the information for me.

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>] On Behalf Of Vanniekerk, Tyrel (GE Healthcare) via wix-users
Sent: Monday, October 28, 2019 8:53 AM
To: wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>
Cc: Vanniekerk, Tyrel (GE Healthcare) <tyrel.vanniekerk at ge.com<mailto:tyrel.vanniekerk at ge.com>>
Subject: [wix-users] Running BA elevated

Hi,

I have seen many many many posts and articles where people try to run the Bootstrapper part of their installer in elevated mode.  The purists will all chime in that it's not supported, should never be done etc., but I have had several cases where our installers (bootstrapper part) need elevated permissions because of silly Windows restrictions.  We 'solved' it, and I say solved, but it's not a real solution in my mind, by having a C# launcher application that has it's manifest set to launces elevated and that has buttons to run the various installers, which are then also running elevated, so no problems.  The installers themselves will give and error if the process is not running elevated, requiring the user to click "Run as Administrator'.  All fine and well, but there has to be a better solution this this, or as I have seen suggested, modifying the WiX Toolset source code to update the manifest files.

Now before you get angry and try to explain why this should never be needed, let me explain.  An option in the bootstrapper XML to enable elevated would be nice, then it's up to the user to decide if they want to do that.

I have two situations I can think of at the moment that I have not been able to get around yet.

  1.  One of our installers allowed the user to enter an username/password that the elevated MSI installer would use to create a local user for batch processing.  Problem is, Windows requires an elevated process to check the username and password policies.  So the installer was not changing anything, but it could not ensure the username and password were valid for Windows, so the MSI portion could fail.  Not acceptable.
  2.  I have not found a way yet (other than forcing our internal MSI to run in repair mode during a change, not desirable) to get the MSI installer to update our registry settings during modify mode.  The component is already installed and I don't see a way to get it to update.  So I a left to either create a custom action to update the registries manually, having to duplicate the code that was in the registry component, or I have the bootstrapper update the registry at the start or end of the install, which requires elevated permissions.
  3.  I think there was another case where I needed to check if all the required IIS components were installed that also required an elevated process.

So, other than possibly religious reasons, why is the option to run BA elevated so strongly blocked?

Thanks,
Tyrel

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/