A look at the changes programmers need to make for compatibility with Vista’s UAC.

Vista’s User Account Control (UAC) may seem like a strange topic for a programming column, but Microsoft designed this feature with programmers in mind.

The idea is to force them to build applications that work properly when users are not running with full administrative rights.

Presuming the strategy works, some future version of Windows will be even more locked-down by default. Windows guru Mark Russinovich, who now works for Microsoft, explained this in detail on his blog .

He said: “Windows Vista introduced elevations and Integrity Levels (ILs), even though there is no guarantee your elevated processes aren’t susceptible to compromise by those running at a lower IL: [Microsoft wants] to get us to a world where everyone runs as a standard user by default and all software is written with that assumption.

“Without the convenience of elevations, most of us would continue to run the way we have on previous versions of Windows – with administrative rights all the time.”

The essence of User Account Control is that all users run as standard users, with read-only access to system locations such as the Windows directory, Program Files, and the Hkey_Local_ Machine section of the registry. This applies even if you are running as a local administrator.

On occasions when you need real administrative rights, Vista raises a dialogue on a separate desktop inviting you to allow or cancel the action. This is called elevation. However, once it is approved, the elevated process runs on the same desktop as the standard user.

The obvious danger is that malware running with standard user rights may be able to trick the elevated process into running malicious code. To prevent this, Vista places restrictions on the extent to which non-elevated processes can communicate with elevated processes.

The degree of elevation is called the integrity level, and Vista actually supports four of these: Low is used for Internet Explorer’s protected mode; Medium for normal running; High for administrative tasks; and System. Processes running at a higher integrity level are protected to some degree from lower level processes, but Microsoft admits to some compromises.

Another feature of UAC is called virtualisation. This is designed to support applications that attempt to write to system locations. When virtualisation is enabled, which it is by default, the write appears to succeed, but the data is not really written to the system location. Instead, it goes to the virtual store, which is hidden in the user’s home folder. By default, this is at C:\Users\yourname\AppData\Local\VirtualStore.

If all your applications are behaving well, this will be empty. Most likely it is not: mine includes folders from Adobe, Borland, Creative, Open Office and Microsoft. The virtual store is ugly. Files written there appear to be in a system location, but only when you run as the user who created them. In addition, elevated processes cannot see the virtual store. There is plenty of potential here for bugs and other unexpected behaviour. The registry also has a virtual area that works in the same way for disallowed registry access.

As Russinovich explains, Microsoft created this elaborate system with one eye on security and the other on compatibility.

The aim is to make it feasible to run old applications that require administrative rights, but sufficiently awkward that developers will stop writing applications that need such rights.

This is not just about shrink-wrap software, but also the custom applications on which many businesses rely.

Should you just disable UAC? This is an option, but it does compromise security. You lose features such as Internet Explorer’s protected mode as well as the elevation dialogue. Furthermore, even if you do disable UAC, it is unreasonable to expect this of other users of your application.

UAC has received a bad press in some quarters for displaying too many dialogues, but the problems are exaggerated. Once a machine is set up, elevation dialogues are infrequent, and they will reduce further still as application compatibility improves.

How to use a UAC manifest

An annoying aspect of UAC is that much of it is automatic. At times this gets silly. For example, Microsoft decided that any application with the word ‘setup’, ‘install’ or ‘update’ anywhere in the name should run with administrative rights. It is easy to call a harmless utility UpdateSpreadsheet or something, and then wonder why it is displaying a UAC prompt.

The solution is to make your utility UAC aware, by embedding a manifest. You can use this either to prevent or require elevation for your application.

To embed a manifest in Visual Basic 2005, first create a text file. You can use Visual Studio for this. The key setting is the line:

<ms_asmv2:requestedExecutionLevel

level=’asInvoker’ uiAccess=’false’/>

Change the value of the level attribute to ‘requireAdministrator’ if you need to enforce elevation. Save the file as UpdateSpreadsheet.manifest, for example.

Now you have to embed the manifest in your application. To do this you need the mt.exe tool, which is part of the Windows SDK, a free download. If you have the full version of Visual Studio, mt.exe is installed with it. To use it, open a Visual Studio 2005 command prompt, or any command prompt with mt.exe on the path. Navigate to the folder where your manifest is saved and run the following command:

mt -manifest UpdateSpreadsheet.manifest - outputresource:bin\Debug\UpdateSpreadsheet.exe;#1

Substitute the path to the application for the output resource. The result is no UAC prompt because asInvoker was specified. The virtual store is also disabled for this application. If you have the full Visual Studio 2005, you can add the manifest in an automatic post-build step – see Project Properties, Compile, Build events.

Setup hassles

Once you have created your application, you might want to build a setup for it using a Visual Studio Setup project.

You can create one automatically using the setup wizard in Visual Studio 2005. This builds a setup file using the Windows Installer technology. On the surface this seems a handy tool, but dangers lurk.

The Installer API is among the most arcane and complex in Windows. Everything is fine if you just want to use a single executable, but once you start adding extra files or customising the installation process, there are many potential pitfalls.

One of the Microsoft installer team members wrote a document called the Tao of the Windows Installer. It contains no less than 69 rules you should observe to create a well-behaved setup. It is true that many of these are not relevant to a simple, non-corporate install, but even trivial tasks can trip you up, especially when combined with UAC.

For example, the Windows installer is designed as a database, the idea being that concepts such as commit and rollback are useful when installing applications. One problem is that many setup routines require procedural logic to accommodate user preferences, or different scenarios such as versions of Windows and upgrades versus new installations.

Procedural logic is an uncomfortable fit with the database model. The installer gets round this by allowing for ‘custom actions’, which are scripts or executables you can fire during the install. Even Visual Studio setup projects allow for these, in the Custom Actions editor.

Now imagine your custom action has to copy some files to Program Files, or make other system changes. Even on Vista, setup routines almost always run with administrative rights, so you would think this would be fine, but this is not so. Custom Actions can be of two types – deferred or immediate.

For various reasons, deferred Custom Actions are generally more useful, so Visual Studio creates these by default. However, they are executed using a feature called impersonation, which means that even though the setup has full rights, the Custom Action has only the standard rights of the current user; they are not elevated.

You can overcome this by changing the type of the Custom Action to switch impersonation off, but you cannot do this within Visual Studio. You have to use a clunky tool called Orca, which is a database editor for Microsoft Installer (msi) files, or else use a different setup tool.

Even then there are problems. When you switch off impersonation, the Custom Action runs as System. This means it probably has limited network access. If your users run the setup from a network drive, it may fail.

Also, Custom Actions can be DLLs or executables. It is tempting to make them executables, so they have their own user interface. However, this is not usually a good idea. If your Custom Action displays a dialogue, it may well appear behind the Installer window. Your users will probably think the setup has hung. The solution is to make the Custom Action a DLL, and call functions in the Installer API to display messages and dialogues.

Visual Studio setup projects are not for the faint-hearted. It is best to use other options, such as one-click install, which is the Publish option on the Visual Studio Build menu. Windows Installer is unavoidable in some scenarios, as many Windows management tools assume its use. PCW

Title: Hands on: Vista’s User Account Control
Author: Tim Anderson
Date: 4 Jun 2007
Source: IT Week