responses inline:
> From: d...@vulscan.com
> Date: Wed, 17 Jul 2013 08:15:51 -0700
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Understanding WiX elevation and BHO
>
> Hey Blair,
>
> Thank you for the input. Great insights here.
>
> I already have the InstallScope to "perMachine", but I do have
> InstallPrivileges="elevated". Are you saying I SHOULDN'T do that? My
> understanding from the WiX docs is that this is required if you need the
> caller to be in an admin context. if its perMachine and without
> InstallPrivileges, is the /privileges=admin in the CustomAction going to
> force the elevation?
@InstallScope does two things: 1) provides an initial value for the property
ALLUSERS, and 2) performs the same settings as @InstallPrivileges. Supplying
both opens the possibility of making those settings inconsistent, thus
@InstallPrivileges should be deprecated.
> As for my BHO, I am not registering it from within BHO. The 3rd party
> framework we use includes a cmdline exe that does the registration to
> everything. The CustomAction looks as follows:
>
>
> <CustomAction Id="RegisterApp" BinaryKey="their-bho-registrator_exe" Execute
> ="deferred"
> ExeCommand='/install="[INSTALLFOLDER]$(var.Our.App.TargetFileName)"
> /privileges=admin /returnExitCode=false' Impersonate="yes" />
>
>
>
> I am assuming that it is this CustomAction that isn't behaving right when
> not executed from an elevated cmd window.
@Impersonate="yes" means that the custom action will run with the same user
token as the original MSI was launched with. That means that if you don't
preelevate you get the non-elevated token (and thus, operations requiring
elevation will fail). Your third-party framework is performing a form of
SelfReg, and all of the evils associated with it still apply. Push back to them
to supply the actual registration. SelfReg is only ever appropriate for
developer boxes that require the component to be registered in order to
program/debug against it (and even then only if your developer box is in a VM
and can be easily rolled back).
> I am going to look into Andreas' suggestion of manually applying the
> registry keys instead, but before I do that, I would like to take the time
> to learn how the CustomAction in WiX is functioning. Will help me to figure
> out the trust boundaries / elevation management within the framework. We
> have been spoiled with a UX for building installers for years, and the
> move to WiX is a blessing and a curse. So much more to learn to do this
> right. Look at the series of blog posts by Robert Flaming starting here:
> http://blogs.msdn.com/b/rflaming/archive/2006/09/20/uac-in-msi-notes-introduction.aspx
> (find all posts with the title prefixed with "UAC in MSI Notes:" from this
> query: http://blogs.msdn.com/b/rflaming/archive/tags/uac+in+msi/)
> Regards,
> Dana Epp
> Microsoft Security MVP
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
