Run unelevated custom action from a WiX elevated installer started by DNI

[Stenio Brunetta]

I'm trying to figure out how to run a custom action from an elevated WiX installation setup program. The msi file generated by WiX is executed by DotNetInstaller.

In WiX I have a Package section with InstallScope set to perMachine and this custom action:

<CustomAction Id='RegisterPlugin' FileKey='RegisterPluginExe' ExeCommand='' Return='asyncNoWait' Impersonate='yes' />

<InstallExecuteSequence>
  <Custom Action='RegisterPlugin' After='InstallFinalize'>NOT Installed</Custom>
</InstallExecuteSequence>

Impersonate set to yes should run the action exe as the user who run the DNI bootstrapper. The custom action should read a file in the user AppData directory, using the value obtained by System.Windows.Forms.Application.LocalUserAppDataPath, but the directory used is wrong because is the one of the Administrator user.

I tried to use a manifest to run DNI unelevated, but the problem remains. If I run the msi directly, it correctly does some registry operations which require administration rights, while the custom action runs as expected.

Any suggestions?

Thanks, Stenio

[Daniel Doubrovkine]

So DNI runs elevated? In this case both the MSI immediate custom actions and deferred ones run with administrative privileges. So I think you're on the right track to start with an un-elevated DNI.

Now, when you do that and you're not prompted for elevation, you're saying the MSI executes differently than when you do it from the command line. That's weird. DNi would just kick it off as you would from the command line. Get a detailed log of both and compare them. What's the difference?

--
You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

dB. | Moscow - Geneva - Seattle - New York
code.dblock.org - @dblockdotorg - artsy.net - github/dblock

[Stenio Brunetta]

I can see from the taskmanager that the user is OK when DNI starts using the manifest as below

      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
      </requestedPrivileges>

than when the msi starts I'm prompted for elevation and I can see the user become Administrator on the task manager.
If I run the msi directly the user remains the same even after the elevation. It seems that only the privileges are affected.

Regards,
Stenio

[Daniel Doubrovkine]

Is the msi executed via msiexec (in both cases)? Is the MSI an MSI component in DNI or a command-line thing? 

There're different way DNI can launch a process, maybe that matters.

--
You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stenio Brunetta]

It is a MSI component, not a simple command.

[Daniel Doubrovkine]

I would try to see if it changes anything by making it a CMD component and playing with these options, but frankly, I am not sure what's going on.

On Mon, Jan 20, 2014 at 4:01 PM, Stenio Brunetta <stenio....@gmail.com> wrote:

It is a MSI component, not a simple command.

--
You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stenio Brunetta]

The user is OK using a CMD component, indipendetely from the execution_method setting. But now I have two problems:
first a black dos window appears during the installation and, more important, the user is prompted for elevation on every component that requires administration rights! :(

[Daniel Doubrovkine]

Ok, this makes sense. Msi components are executed via CreateProcess (see https://github.com/dblock/dotnetinstaller/blob/91133580987e570eaf8d1870620c11b898050f44/dotNetInstallerToolsLib/ShellUtil.cpp#L100), which inherits all the security attributes of the calling process, while command components use Shell. That's the window you're seeing. I'm sure it's possible to launch the process in a way not to see the shell window, or to launch it via CreateProcess fixing your underlying issue, but I don't think this is something I can help with.

Of course, since elevation happens in each MSI, you're getting the behavior that you see.

So, if this is a per-user MSI, it should just run un-elevated. If this is not a per-user MSI, the question is, why is it trying to modify something that belongs to 1 user? Should it not be modifying that something for all users?

--
You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stenio Brunetta]

Actually I tried with both execution_methods defined in DNI 2.3 and the behavior was correct in either cases, when using DNI unelevated with the manifest.

The application I'm developing is composed by a lot of plugins wich are executed by a preinstalled program made by a third party. The program find the plugins reading a user config.ini file. So, in order to avoid the user to set his ini file by himself, I wish to edit this per-user ini file during the installation of  the chosen plugin.

[Daniel Doubrovkine]

Oh so you were doing this with an older release? Do I understand this correctly that everything is working with MSI components in 2.3, too?

I think your scenario is not something I'd expect from an installer. But you can also just pass the current user info into the MSI from the bootstrapper maybe?

--

You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stenio Brunetta]

No, with older releases the problem was still present and with MSI components I'm not able to achive what I need: I have to use a CMD component to have the user unelevated when the .msi starts.
Knowing the user who started the bootstrapper can help because then from the msi I can run a command via runas.

[Daniel Doubrovkine]

Might need a change here: https://github.com/dblock/dotnetinstaller/blob/master/dotNetInstallerLib/InstallerSession.cpp#L87 to expose something like #USERNAME.

--

You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stenio Brunetta]

That variable would definitively solve the problem.

[Daniel Doubrovkine]

Please contribute!

On Sat, Feb 15, 2014 at 4:06 AM, Stenio Brunetta <stenio....@gmail.com> wrote:

That variable would definitively solve the problem.

--
You received this message because you are subscribed to the Google Groups "dotnetinstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnetinstall...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.