[wix-users] Custom Action with elevated privilege

Fri Dec 14 11:21:07 PST 2018

The phrase "configure before install" doesn't sound like what I was
suggesting. I am proposing a *separation* between _gathering_ of
configuration data and the act of applying that data to the application's
configuration. This separation really exists no matter which approach is
taken. You do not need elevation to gather the data from the user and that
activity should occur in a non-elevated context. The act of applying the
data to the application's configuration can happen in lots of ways, and
depending on the application, may require many different types of
configuration to be updated: INI files, XML files, registry values, etc. In
my personal experience, doing first time configuration is not too
difficult. The difficulty really lies in upgrades where configuration
schema and/or data must be migrated.

When I have an opportunity to influence design I typically call out the
following different types of configuration data:

* Runtime settings - These are typically overrides for user settings.
Typically configured at the command line.

* User settings - These are typically overrides for system-level settings.
Typically configured in one or more per-user files, registry values, or
environment variables. Files should live in the user's AppDataFolder and
they cannot be reliably written for all users at install-time. The
application really must be responsible for helping the user manage these
settings.

* System settings - These are typically overrides for default application
settings. Typically configured in one or more per-machine files, registry
values, or environment variables. Files should live in CommonAppDataFolder.
The installer could write these settings at install-time if the installer
has gathered the data at install-time. Data migration might still be better
managed by the application itself so perhaps the application should be
responsible for managing system settings too just like user settings.

* Default application settings - These can be hard-coded default settings
compiled in to the application's binaries or could be exposed as a default
configuration file that is *NOT* to be modified by administrators or users.
Such data is typically configured in one ore more per-machine files,
registry values, or environment variables. If they exist in files, they
could live in ProgramFilesFolder as they are not to be modified but
CommonAppDataFolder is also a reasonable location but easier to modify
accidentally.

* Application configuration for frameworks and libraries - These are never
to be modified and are not settings at all. Often frameworks and libraries
use configuration files for these. Like default application settings, these
could live in ProgramFilesFolder as they are not to be modified but
CommonAppDataFolder could also work but easier to modify accidentally.

Quite often, I see system settings, default application settings, and
application configuration for frameworks and libraries stored together in
the same physical location. Often the installer writes the default
application setting by default unless it has been configured at
install-time and then it writes the system setting instead. This makes
migration very, very difficult and unintentionally encourages
administrators to modify application configuration for frameworks and
libraries that are not to be modified ever!

I would actually encourage that all these different types of configuration
be stored separately in different physical locations (different files,
different registry keys). Anything that should never be modified by
administrators be stored in ProgramFilesFolder and is the installer's
responsibility to update during upgrades. If anybody changes these between
upgrades then the installer can and should simply replace the old, modified
data with the new data as the installer understands the data should be.
System and user settings should be managed (migrated, etc.) by the
application itself. The installer could gather the data for the user's
convenience and ask the application to reconfigure itself but if the
application still needs to have the ability to gather the data itself, then
that logic shouldn't be duplicated in the application and installer. My
personal preference is to make the installer as "dumb" as possible as it
relates to data and relocate data management into the application where it
can be as "smart" as is necessary.

--
Edwin G. Castro

On Fri, Dec 14, 2018 at 9:33 AM Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> They have several options, both with their own pro’s and con’s.
>
>
>
> Configure on first run: This is a commonly accepted solution, but it
> should not require administrative rights to do so.  In order for this to
> work, the application and configuration tool would need to be updated to
> use the CommonAppDataFolder instead of ProgramFilesFolder for storage of
> the settings.  Depending on the application, one could also allow per user
> configuration to make a copy on first run (or on first modify) to
> AppDataFolder.
>
>
>
> Configure before install: This can work as well, but requires you to
> duplicate your configuration logic in a MSI or bundle and property drive
> the configuration to have the MSI securely write to the ini in the
> ProgramFilesFolder.
>
>
>
> Configure after install with elevation: Least desirable (security concerns
> w/ config.exe modifying machine state in a non-transactional manner).  The
> user is trying to do this without success from just a MSI.  I know it can
> be done with a bundle (see my other email) with minimal UX impact. The MSI
> route is going to trigger a second UAC prompt and would require the
> config.exe to be manifested (which it should be if it requires access to
> ProgramFilesFolder).
>
>
>
>
>
> *From:* Edwin Castro [mailto:egcastr at gmail.com]
> *Sent:* Friday, December 14, 2018 11:16 AM
> *To:* WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> *Cc:* Hoover, Jacob <Jacob.Hoover at greenheck.com>; WJia at liaison.com
> *Subject:* Re: [wix-users] Custom Action with elevated privilege
>
>
>
> It sounds like you are trying to interact with the user for configuration
> *after* the installation has completed. If you read the comments made by
> Christopher and Jacob carefully, you will see they are expecting you have
> already collected the configuration data before the install transaction
> begins. In such a case then you have the option to write the data to a
> temporary location at install-time that the application can read (and clean
> up) to configure itself at first run since, presumably, the application
> runs with enough permissions to configure itself. If you were gathering the
> configuration *before* the install transaction began, then you could simply
> run the configuration executable before InstallFinalize to complete the
> configuration. Of course, the configuration executable no longer would
> require a UI since all the configuration data has already been retrieved
> earlier on. The installer's responsibility is just to pass the data to the
> configuration executable. The details of how the installer and the
> configuration executable communicate is just a contract between the
> installer and the configuration executable. You could use command line
> arguments, a temporary file, a temporary registry key, a named pipe, etc.
> You have lots of options.
>
>
>
> I would encourage you to design your installer to retrieve the
> configuration data early rather than as a separate step at the end that
> happens after the installer has completed. I would also encourage you to
> think about upgrades and how this process should discover the current
> configuration settings so that the user doesn't have to provide the
> settings on upgrade.
>
>
>
> --
> Edwin G. Castro
>
>
>
>
>
> On Fri, Dec 14, 2018 at 8:37 AM Wenzheng Jia via wix-users <
> wix-users at lists.wixtoolset.org> wrote:
>
> The config.exe basically is a configuration tool that retrieves the
> settings for a customer and writes them to an ini file. The issue I'm
> having right now is that after the config.exe is invoked, the user can go
> through all the config settings. It's at the time of writing the config
> file to the installation folder, that's where the issue is. It requires a
> higher level of privilege to be able to write the ini file to the
> installation folder.
>
> We currently have an NSIS script to do so. That installer is working as
> expected. We are trying to move to the WiX ToolSet but running into this
> issue. Grantly, I'm still new to the toolset and still trying to figuring
> things out as I convert them.
>
> Wenzheng
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> Christopher Painter via wix-users
> Sent: Friday, December 14, 2018 10:01 AM
> To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; WiX Toolset Users Mailing
> List <wix-users at lists.wixtoolset.org>
> Cc: Christopher Painter <chrpai at iswix.com>
> Subject: Re: [wix-users] Custom Action with elevated privilege
>
> I believe we are in 100% agreement.  I don't know what his config.exe is
> doing so it's impossible for me to say what the proper solution is.
>
> ________________________________
> From: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Sent: Friday, December 14, 2018 9:53 AM
> To: Christopher Painter; WiX Toolset Users Mailing List
> Subject: RE: Custom Action with elevated privilege
>
>
> First run is fine, but it shouldn't require elevation to configure the
> application. There are well defined locations where an application can
> store configs (either per user or per machine) which don't require
> elevation.
>
>
>
> The issue with "but I just want to write this 1 file" is there is nothing
> preventing it from changing anything else.  And typically the installer
> developer and the app developer are different people, so while the 1 file
> may be true today it may not be tomorrow. Hence why if it has to be in a
> restricted location, it should be written/updated by a CA in the installer.
>
>
>
> From: Christopher Painter [mailto:chrpai at iswix.com]
> Sent: Friday, December 14, 2018 9:48 AM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Subject: Re: Custom Action with elevated privilege
>
>
>
> Handling config in an MSI can be a pain.  Running an EXE after the install
> can be a good compromise.  Usually when I do it  I make it optional and I
> have the make program call it on first run if configuration hasn't
> occurred.  I usually put the configuration data in a registry key or folder
> that doesn't require elevation.   This usually works well.
>
>
>
> I typically only handle configuration in the installer when it's needed to
> execute sql scripts or setup a windows service or application with a
> certain account.  Otherwise I tend to push it to application first run.
>
>
>
> ________________________________
>
> From: wix-users <wix-users-bounces at lists.wixtoolset.org<mailto:
> wix-users-bounces at lists.wixtoolset.org>> on behalf of Hoover, Jacob via
> wix-users <wix-users at lists.wixtoolset.org<mailto:
> wix-users at lists.wixtoolset.org>>
> Sent: Friday, December 14, 2018 9:15 AM
> To: WiX Toolset Users Mailing List
> Cc: Hoover, Jacob
> Subject: Re: [wix-users] Custom Action with elevated privilege
>
>
>
> Why not write a proper CA that can be ran during the installation
> sequence? What is its need for modifying machine state after the
> installation is complete?
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
> Of Wenzheng Jia via wix-users
> Sent: Thursday, December 13, 2018 9:15 PM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org<mailto:
> wix-users at lists.wixtoolset.org>>
> Cc: Wenzheng Jia <WJia at liaison.com<mailto:WJia at liaison.com>>
> Subject: Re: [wix-users] Custom Action with elevated privilege
>
> I changed the manifest of the configuration executable. Now the event
> doesn't trigger the configuration executable's UI to show up at all. Any
> thoughts?
>
> Wenzheng
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org<mailto:
> wix-users-bounces at lists.wixtoolset.org>> On Behalf Of Rob Mensching via
> wix-users
> Sent: Thursday, December 13, 2018 4:01 PM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org<mailto:
> wix-users at lists.wixtoolset.org>>
> Cc: Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com>>
> Subject: Re: [wix-users] Custom Action with elevated privilege
>
> Manifest the executable to require elevation
>
> _____________________________________________________________
>  Short replies here. Complete answers over there:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.firegiant.com_&d=DwICAg&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=avZa-T5fw-SOKT3TquIRo1WmRnXgOTWNtV5hFWlvt4Y&s=fig_YK_LGEbx77zlghw1Vgh7yLkHiCkil4caTdKkgo0&e=
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org<mailto:
> wix-users-bounces at lists.wixtoolset.org>> On Behalf Of Wenzheng Jia via
> wix-users
> Sent: Thursday, December 13, 2018 1:56 PM
> To: wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>
> Cc: Wenzheng Jia <WJia at liaison.com<mailto:WJia at liaison.com>>
> Subject: [wix-users] Custom Action with elevated privilege
>
> I'm creating an installer to launch an executable after the installation.
> The executable will only be launched when a checkbox is selected on the
> ExitDialog. I hooked up the CustomAction to the Finish button of the
> ExitDialog box. I'm able to launch the executable. But the executable
> doesn't have the elevated privilege. It failed to save the output file to
> the installation folder due to lack of privilege. Is there any way that I
> can accomplish this?
>
> <Property Id="WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT" Value="Run Wizard to
> configure the Connector config file" />
>
> <Publish Dialog="ExitDialog" Control="Finish" Event="DoAction"
> Value="LaunchFile" Order="999">(NOT Installed) AND
> (WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1)</Publish>
>
>
> <CustomAction Id='LaunchFile' Directory='APPLICATIONFOLDER'
> ExeCommand='[APPLICATIONFOLDER]Config.exe' Impersonate='no'
> Return="asyncNoWait" />
>
> Wenzheng Jia
> Senior Software Engineer
>
> Liaison Technologies
> 3157 Royal Drive | Suite 200 | Alpharetta, GA 30022
> T: +1 888.806.0309 x525
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.liaisonhealthcare.com&d=DwICAg&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=avZa-T5fw-SOKT3TquIRo1WmRnXgOTWNtV5hFWlvt4Y&s=kKXHAPnLhNVfz78aKLK0T8ObJcLe5UxuZYlWuvA_Eg4&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.liaisonhealthcare.com_&d=DwICAg&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=avZa-T5fw-SOKT3TquIRo1WmRnXgOTWNtV5hFWlvt4Y&s=J0tBdN8mP8E_tHcSGJHeix-C1nudBqnt_WzIkpICt78&e=>Connect
> with us!<http://liaison.com/about-liaison/communities>
>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.firegiant.com_&d=DwICAg&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=avZa-T5fw-SOKT3TquIRo1WmRnXgOTWNtV5hFWlvt4Y&s=fig_YK_LGEbx77zlghw1Vgh7yLkHiCkil4caTdKkgo0&e=
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.firegiant.com_&d=DwIF-g&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=aUStesA1Ad3NxOp8Vb7d1nKUDl4GOX8fN-xwbFb5Ndw&s=WHb4koSWv4sZsTm6ULD8emyBzmF_naDhJAbdOAAAgL0&e=
> 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
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.firegiant.com_&d=DwIF-g&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=aUStesA1Ad3NxOp8Vb7d1nKUDl4GOX8fN-xwbFb5Ndw&s=WHb4koSWv4sZsTm6ULD8emyBzmF_naDhJAbdOAAAgL0&e=
>
> 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
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.firegiant.com_&d=DwIF-g&c=PSLapdneSrIm6YCSwp9NIGuZt5KBqytXkQWJ6tZG4UQ&r=1Rm10nvLj379JDc0olGT1Q&m=aUStesA1Ad3NxOp8Vb7d1nKUDl4GOX8fN-xwbFb5Ndw&s=WHb4koSWv4sZsTm6ULD8emyBzmF_naDhJAbdOAAAgL0&e=
>
> ____________________________________________________________________
> 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.
>