"LUA" is an acronym that variously refers to "Limited User Account", "Least-privileged User Account". A "LUA bug," refers to an application or a feature of an application, that works correctly when run with elevated privileges but fails to work for a LUA user, and where there is no technical or business reason for requiring elevated privileges.
LUA comes into play, for example, when an application saves its runtime settings to a registry key under HKEY_LOCAL_MACHINE (which is read-only to LUA users), instead of to HKEY_CURRENT_USER.
Types of LUA bugs:
- Attempting to start or stop a service
- Load a device driver
- Access hardware resources directly
- Create or manage file shares, or even explicitly check whether the current user is a member of the Administrators group.
At the core, there are always one or more low-level operations ("API calls") that succeed when performed as admin but that fail when performed as LUA.
Troubleshooting LUA Bugs
After identifying the bug as LUA-related, those bugs must be resolved. There are many solutions available. However, these approaches have their own benefits as well as drawbacks.
1. Re-Development
If there is no technical reason for the application to require admin privileges, then failure of the application to work for a regular user account is a serious bug that compromises system security, stability, and manageability. Seriously consider having the developers fix the problem directly in the code.
Benefits:
Once the development team has fixed the bug directly in the application code, you don't need to carry forward any shims, tweaks, or workarounds. In addition, the developers may learn from the experience and avoid creating new LUA bugs.
Drawbacks:
The expense in both time and money can be prohibitive, especially if you have limited resources and a lot of apps that need to be fixed. The app may need to be rearchitected, and new bugs may be introduced in the process. Another hurdle is that the developers or the source code may not be available. You could be dealing with third-party code from a company that no longer exists.
2. Application Compatibility Toolkit:
The Application Compatibility Toolkit offers useful LUA Mode shims. These shims detect attempts to write to system wide locations in the file system and registry and silently redirect them to per-user locations.
Benefits:
The really compelling reason for using the LUA Mode shims found in the Application Compatibility Toolkit is that it's easy.
Drawbacks:
On Windows XP, the LUA Mode shims often do not work.
3. Copy Specific HKCR Keys to HKCU\Software\Classes:
If the applications write to HKCR at run time to reinforce their file associations, COM registration data, and so on. An error is raised if the write fails, even if the data to be written is already there. The same data is written every time the app runs. If that same registration data were stored in HKCU\Software\Classes, then the write operations would succeed, without changing program behavior.
To fix this, first you must identify the keys under HKCR that the application is trying to write to. Export those keys to one or more .reg files (in the Registry Editor, select File | Export and choose Selected branch). Then using a text editor, replace all instances of [HKEY_CLASSES_ROOT\ with [HKEY_CURRENT_USER\Software\Classes\ and save your changes. When you're finished, import the edited .reg file into the registry of the user who needs to run the program.
4. Use IniFileMapping:
Many applications, including some Windows applets, still use these APIs to try to write to .ini-formatted files, often in folders where users are not supposed to write.If access to an .ini-formatted file via the Profile APIs is the cause of a LUA bug, it can be corrected by adding a key under the IniFileMapping key to redirect access to HKCU. Note that IniFileMapping is under HKLM, and to configure this you'll need administrative privileges.
Benefits:
This approach avoids loosening access control on systemwide resources in the file system. And again, malware overwriting keys under HKCU will not affect operating system components or other users of the computer.
Drawbacks:
IniFileMapping entries specify the file name only and will affect all Profile API access to any file with that name, in any path. This can have side effects on other apps that have their own ini files with the same name.
Introduction to LUA Buglight Tool
LUA Buglight is a tool, designed to identify the specific causes of LUA bugs in applications running on Windows XP. Once the specific causes have been identified, the bugs can more easily be resolved by fixing the application's source code or by making configuration changes, allowing the app to work correctly for non-admin users.
How LUA Buglight Works....
With LUA Buglight, the target app runs as non-admin. When the target app calls a shimmed API, it actually calls into a LUA Buglight Detours-based DLL. That DLL can then perform various actions, including calling the actual underlying API and inspecting or modifying its results before returning control to the application.
LUA Buglight creates an access token representing the current user but as a member of the administrators group (referred to as the this-user-as-admin token) with full admin privileges. That token is available to the API shim code running within the process.
LUA Buglight creates this token using an approach very similar to that of the MakeMeAdmin script. The core of the LUA Buglight approach is that when the app calls a shimmed API, the shim first calls the underlying API. If that API fails with access denied (or in some cases, privilege not held), the shim takes the this-user-as-admin token, impersonates it, and calls the underlying API again. The result of the second call is what is returned to the application. If the call succeeds as admin, information about the call is written to a log file as a potential LUA bug. The net result is that the app will not fail due to LUA bugs, since it can use admin privileges when needed, but that each case where admin privileges are required is identified.