[wix-users] Running BA elevated

[Edwin Castro]

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> 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]
> Sent: Monday, October 28, 2019 11:02 AM
> To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; WiX Toolset Users Mailing
> List <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>
> Sent: Monday, October 28, 2019 10:04 AM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Cc: Vanniekerk, Tyrel (GE Healthcare) <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] 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
> Cc: Vanniekerk, Tyrel (GE Healthcare) <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/
>