This is the twenty-first in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries
This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs. For this entry the topic is: Do I need to consider "this" when I'm designing for UAC in MSI?
As folks load context from Microsoft's documentation there is a point of synthesis at which they start to ask how does this relate to that. Ideally we could say that 'we've not written anything about this relating to that so one does not relate to the other'. Unfortunately there's history where we've either documentation being wrong or incomplete OR we'd didn't put those two components together to see if they relate.
I like talking to customers about boundaries and relationships because it means they've done their homework. Those customers that are asking because they are experiancing behavior that they are trying to understand are even better. Customers that are already committed are the ones that have most invested and I like helping investors.
What follows is a set of questions that I get about customers "this" list to which I respond generally no.
(note: "this" == certificates as handle for authorization model)
No. This feature is under consideration for future versions of Windows.
Customers are also asking for this type of feature for the rest of the UAC credential prompt situations. Today there is a technology called SAFER that is designed to allow a corporate authority (IT department via active directory) to deny rights to run programs.
The pre-Vista logic underlying SAFER was everything gets to run unless it's denied. The mindset of Vista inverts this polarity, nothing gets to run unless it's allowed. If Vista's inversion of polarity sticks in the market, it begs the question of whether SAFER's polarity should be inverted.
(note: "this" == manifesting of dependent system binaries)
No. MSIExec.exe runs asInvoker when run as a client, as Local System when run as a service, and per custom action attributes when run as a custom action server. Generally, system binaries are under the protection of Windows Resource Protection so there would be nothing a customer could to do a the manifested system binary was "wrongly" manifested.
(note: "this" == heuristics behind credential prompts)
No. There is a single elevation dialog for an entire install. After receiving correct credentials, the msiexec service manages the elevation context per the attributes of the custom actions. If a custom action is marked NoImpersonate, which custom action is run in the elevated sandbox.
We have heard sproratic cases of EXE custom actions triggering a credential prompt. If an EXE custom action is causing a credential prompt, there are two cases 1) the Installer Detection heuristic thinks the binary is a setup bootstrapper that needs to be elevated or 2) the binary was manifested to requireAdministrator. To prevent either case, explicitly manifest the binary asInvoker.
(note: "this" == capacity to update WRP)
No, the files and registry keys under the jurisdiction of Windows Resource Protection (WRP) are only modifiable by the Trusted Installer. The Trusted Installer is a new service for Windows Vista which does not talk to the Windows Installer. Trusted Installer updates are controlled entirely by Windows so an update to those resources must be done through the Windows servicing system.
(note: "this" == UAC Virtualization Technology)
No, the UAC virtualization technology works during the execution of the applications to mitigate some of the application compatibility problems Windows has seen with pre-Vista applications. Please see the User Account Control documentation for further information on how the virtualization technology affects running applications.
(note: "this" == UAC user experiance mitigation RunAs)
No. The work in the shell to support Run As Administrator for an advertised shortcut was not performed for the Windows Vista release.
(note: "this" == capacity to write ACLs during install events)
No. Many tools vendors provide their own library that is richer than the existing LockPermissions standard table and LockPermissions standard action. We recommending considering those solutions.
(note: "this" == creating fully custom experiance using External UI Handler)
No. The UAC credential dialogs are from a low level system service and can not be modified or superseded.
(note: "this" == corporate deployment technologies)
No. Corporate deployment technologies use a service running as Local System on each client thus will be unaffected.
(note: "this" == shield ui construct)
No. We do not have enough data about what follows a UI control to know for certain what the last UI control is before switching to the service where the elevation prompt will occur.