What is a "LUA Bug"? (And what isn’t a LUA bug?)

First, what is “LUA”?

“LUA” is an acronym that variously refers to “Limited User Account”, “Least-privileged User Account”, “Least User Access”, and probably several other clumsy phrases that ultimately indicate a computer user account that cannot make changes that affect other users of the system or the operating system itself.  In Windows, these are typically members of the built-in “Users” group; they are explicitly not members of powerful groups such as “Administrators”, Power Users”, or “Backup Operators”, and do not hold elevated privileges such as “Load and unload device drivers,” “Take ownership of files or other objects,” or “Act as part of the operating system”.

A “LUA bug,” then, 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.  A common example is 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.

Windows doesn’t allow LUA users to change the system time.  That is not a LUA bug, because changing the system time has security implications with respect to auditing and to the Kerberos protocol.  The fact that Windows XP doesn’t allow LUA users to change the time zone is arguably a LUA bug, as is the fact that double-clicking the clock in the taskbar’s notification area gives you an error message instead of a read-only view of the Date&Time applet.  (Note 1:  Vista is heavily focused on a more seamless LUA experience — see the UAC blog for more info — and the Date&Time applet is a primary target for an upgraded experience.  Note 2:  I wrote an earlier post about how to grant a Windows XP user the ability to change the date, time and/or time zone.)

By far, the majority of LUA bugs are due to registry and file system access.   A program might try to save its settings into its installation folder under %ProgramFiles%, or it might try to open a key under HKLM for “All-Access” even if it only ever needs Read access.  However, there are other 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.  You can see some of these yourself using tools such as SysInternalsRegmon and Filemon.  However, is every one of these a real LUA bug?  The answer is that it depends on how the application responds to the failure.  The responses I have seen can be categorized in one of three ways:

  • “Fire and forget”:  The application invokes the operation, doesn’t check the result, but doesn’t depend on the operation having succeeded in order to continue working correctly.  This is not a LUA bug.

  • “Gracefully degrade”:  The application invokes the operation, checks whether it succeeded, and handles failure in an appropriate way.  This is not a LUA bug.

  • “True LUA bug”:  The application invokes the operation, assumes it succeeded, and depends on the operation having succeeded in order to continue working correctly.  A variation on this is that the app checks whether the operation succeeded, but handles the failure inappropriately, such as by displaying an error message and falling over dead.

If you’ve ever monitored a GUI app running as LUA with Regmon, you’ve probably come across an example that could be categorized as fire-and-forget:  a failed attempt to open HKLM \ System \ CurrentControlSet \ Control \ MediaProperties \ PrivateProperties \ Joystick \ Winmm for All-Access.  This occurs during initialization of the joystick subsystem for the process.  The specific operation fails, but it does not impact the correct behavior of your application.  However, I have seen “guidance” on the web (no doubt from people misinterpreting Regmon output) claiming that to fix some particular application you need to grant the user full access to this key.  No!  It’s not a true LUA bug.  You should never need to change permissions on this key!

Before you go making wholesale changes to security settings, you should verify that you’re remediating a true LUA bug and not just a phantom, and that there aren’t better ways that don’t increase exposure.  More on that in upcoming posts.


Comments (37)

  1. larso says:

    I agree that it should not be up to a unprivileged user to change the system time, but it should be possible to change the time zone. Changing time zone should not change the system time (which should be in UTC), but should change the local time presented to the user, based on UTC, time zone and summer time changes.

  2. Keith Pawson says:

    That’s a good point Aaron – System time is probably one of the features that has turned people off with running as LUA. They usually don’t understand Kerberos and why this has been restricted. I’m sure a better pop-up message box and read-only display would be very welcomed by all.

    Perhaps Vista will also have other more user friendly message boxes 🙂

  3. Aidan Corey says:

    I don’t think that changing the time (or timezone) is the primary use case for the Date/Time applet.

    It’s a pop-up calendar, for working out what day of the week the 17th will be, or what the time is in another timezone.  It should be capable of doing this without requiring rights to change the clock (or timezone).

  4. Aidan:  actually, its original purpose was explicitly to set the date, time and time zone.  (See http://blogs.msdn.com/oldnewthing/archive/2005/06/21/431054.aspx)  People started using it for reference, or to watch the cool time zone map (remember when it used to draw a highlight over the selected zone?  http://blogs.msdn.com/oldnewthing/archive/2003/08/22/54679.aspx).

  5. LUAcrazy says:

    Great stuff Aaron!!

    I have been wrestling with LUA issues for some time now. Mostly, trying to help admin an SBS2003 domain while trying to keep all the WinXP desktop users running with LUA.

    As was stated, Quickbooks was a big pain (why do they need full access to the HKCR registry?), although Intuit has a list of privileges required, so I was at least able to get the LUA users running with Quickbooks by setting elevated privilege workarounds for users of that app.

    My latest pain seems to be finding work-arounds so the LUA users can use camera and printing software (i.e Kodak Easyshare, HP, Epson, etc.). There are users that need to use these apps for capturing and printing photos.

    Also, please provide some pointers for XP Home LUA (trying to get home computers locked down). In WinXp Pro, it is relatively easy to elevate user privileges to specific folders, files, and registry keys as workarounds for LUA users. However, in XP Home I can’t find a way to do this.

  6. LUACrazy:

    I’m not familiar with the specific issues that Kodak, HP, Epson, etc. cause.  Have you contacted the vendors?

    [No help there – but a helpful tip coming in the next paragraph…]

    Re the last issue you raise:  Windows Explorer offers splendid ACL editors in the Properties dialogs for folders and files – the "Security" tab, which is normally not shown in Home Edition.  The "Security" tab does appear if you boot in SAFE MODE.

  7. Mike Stoltzfus says:

    Aaron – I was convinced about use LUA during your session at TechEd this past year.  Thanks for preaching this – it helps me sleep a little easier at night.

    One issue I’ve had is that various warning messages displayed in Internet Explorer 6 do not disappear even if a LUA user checks the box that says "In the future, do not show this message".  I’ve been searching for a solution for this, but have come up empty.  Any thoughts?

  8. Mike Stoltzfus – I haven’t seen that problem.  There is at least one dialog I know of that doesn’t offer the "in future" checkbox, but the ones that do always obey, as far as I can tell.  If you’re running IE using the "Protect my computer" option, then they probably won’t stick.  Which dialogs are disobeying you?

  9. A systematic approach for working around LUA bugs that avoids unnecessary exposure

  10. Mike Stoltzfus says:

    Aaron – It must be the "Protect my Computer" option, because when I run as a limited user, they don’t obey the checkbox.  (Showing a little ignorance here:) What exactly is the "Protect my Computer" option?  Is that something set through group policy?

  11. Mike Stoltzfus – Setting "Protect my computer" will prevent the program from writing to HKEY_CURRENT_USER in the registry, and will prevent even *reading* from your Docs&Settings folder in the file system.  Some more info here:


  12. Complete list of Aaron Margosis’ non-admin / least privilege posts, for easy lookup.

  13. ML says:

    I’m having trouble accessing Works 8 calendar as under LUA.  Any work around for this?

  14. trebor says:

    i have a friend who’s internet doesn’t work when on a lua..but it does for the admin account.  as far as i know, they have changed no other settings for this to happen, but it does.  any ideas would be great! thanks!

  15. A systematic approach for working around LUA bugs that avoids unnecessary exposure – "the rest of the story"

  16. ML – was the calendar created by a different account from your LUA account?  If so, permissions need to be changed on the calendar file.

  17. D Robinson says:

    I am having a LUA problem – mine is when i log into a LUA, i get a "fAIL" error message, yet it still loads.  I changed this account to an Admin and it loads without the fAIL message.

    It seems to be just an annoyance – but i would like to get rid of it.

    I was told by others to take the system back to the factory defaults, but was hoping someone here had a "better" suggestion….

    any suggestions?  oh, I am familiar with the registry and also periodically back up my system

    thanks, in advance…

  18. D Robinson – from what you’re describing, it sounds as though there is a program that automatically starts when you log on that has a LUA bug.  The best tool for identifying "autostart" programs is Autoruns from sysinternals.com – that will help you narrow down the cause:  http://www.sysinternals.com/Utilities/Autoruns.html

  19. James Cannon says:

    The whole date and time issue can be resolved with DesktopStandard Tools (www.desktopstandard.com) , I have been using them for over a year now, they are the easiest and simple solution to all the LUA problems I have had. Sounds like a plug, but I have really been impressed with them so thought I would share my experiences

  20. James Cannon – I talk about DesktopStandard in "Fixing LUA Bugs, Part II" – you should read that.  I also published a simpler solution to the date/time issue.

    Fixing LUA Bugs, Part II:


    Changing the system date, time and/or time zone:


  21. Anthony C says:

    trebor:  I had the same problem a while ago.  Pre  Service Pack 2 I think.  If I remember correctly it affected me on LAN provided ‘net access, and dial-up seemed fine.  I discovered that non-IE based programs worked under LUA.


  22. More info on the risks of changing access control lists to fix LUA bugs.

  23. "Why does Application XYZ need to run as admin?"

  24. One way of coping with the challenges corresponding with "the principle of least administrative privilege"

  25. On the second Tuesday of the month Microsoft introduces updates for it's products. As a system administrator

  26. John Bokma says:

    An upgrade to the well known vector drawing program Xara Xtreme (which has minor issues with limited user rights) has been released which just doesn’t run with limited user rights, see: http://johnbokma.com/mexit/2006/12/11/xara-xtreme-pro-crippled.html

    A drawing program that requires Administrator rights for making a simple drawing.

    I contacted Xara, but other things have higher priorities, and it’s unsure when this will be fixed. Since the minor issues with Xara Xtreme regarding limited user rights have been reported over a year ago I am not going to hold my breath.

    It’s a sad day when software companies release "Pro" software that just assumes that everybody is running with Administrator rights, and hence promote unsafe Windows XP usage this way.

  27. Mike O'Grady says:

    I suppose, like many developers, I haven’t been aware of all of the issues with LUAs. However, I have recently been forced to face up to the issue by a customer who insisted that my accounts and payroll software be capable of running in a LUA. and accessible to all users.

    So, I revamped my code, moved the database from the Program Files directory to C:Documents and SettingsAll UsersApplication DataCompanyApplication. I also set the private directory for the database (for SQL results) to the same path and put the application’s ini file (Yes, an ini file!!) and some temporary database tables in the same place.

    Ran the app from a LUA and yippee – it worked. Except… it didn’t work on my customer’s PC. Apparently, it gets an access error when it tries to write to the ini file. You might say that I should put the ini stuff in the Registry but, if it cannot write to the ini file it is hardly going to be able to write to the database!!

    I have asked the customer to try editing the ini file from the LUA and he cannot save any changes. I thought he might have inadvertently made some of the folders/files read-only, but he says that this is not the case.

    Any ideas on why he cannot write to the “All UsersApplication Data ” sub-folders would be greatly appreciated. This is the Common AppData folder. Surely all users should be able to write to it??

    Mike O’Grady

    Aquila Technology

    Mike — I think what’s happening is because the common data folder has some interesting ACLs.  Any user can create a file or subfolder under there, but only the user who created a particular object gets Full Control over it — all other users get Read&Execute only.  (This is the effect of the inherited CREATOR OWNER entry in the ACL.)  If the data files are to be shared by multiple users (I assume they are or you would just put them in the user’s private folders), then I would recommend that you create the folder in which to put the data and change the ACL on it so that all authorized users are granted all necessary access to the files within.  (You should review this post regarding the risks of shared data areas.)

    You mentioned “databases” and “SQL”.  I assume you’re referring to something other than SQL Server or related technologies like MSDE.  If you are referring to a database technology that uses a service, then you don’t need to put those data files in the common app folder, since users do not interact directly with the data file(s) but instead with the service.


    — Aaron

  28. I did the same thing as Mike O’Grady with the same results. Upon calling Microsoft support, I was told to put any fully shared data into C:Public (also known as C:UsersPublic). This works without any need for changing ACL or any user administration. However, there is no CSIDL lookup for Public. This makes me concerned that using this folder is not officially supported. Any comment on using C:Public over C:ProgramData (which apparently is an alias for C:Documents and SettingsAll UsersApplication Data and can be looked up using CSIDL_COMMON_APPDATA)?

    David:  There isn’t a C:Public, but there is a C:UsersPublic.  That will get you the default ACL you want, but those folders are really for items that users can browse/discover/interact with directly, rather than ProgramData which is intended for programs to manage.  I would expect the better recommendation would still be to create a custom folder in the app-data folder and set its ACL appropriately.

    For the CSIDL, see this post and follow its links.  The relevant ID is FOLDERID_Public.


    — Aaron

  29. More info on the risks of changing access control lists to fix LUA bugs.

  30. Henning Plumeyer says:

    nbtstat does not work for a limited user, only for admins.

    Is this a LUA bug? I think the option -n for example does no change to the system and does not read non-public information — so it is a LUA bug.

    How can I work around this? I have tried LUA buglight (starting cmd.exe, then nbtstat -n ) but got no helpful result.

    With the option -a you can ask a remote system’s NetBIOS name table. You need local admin rights but not on the remote machine!

    [Aaron Margosis]  I just tried nbtstat using (separately) -c, -r and -n.  All of them seem to work on my Vista machine.

  31. Henning Plumeyer says:

    I have tried on Windows XP and Server 2003 only.

  32. Henning Plumeyer says:

    Problem occurs on Windows XP and Windows Server 2003:

    nbtstat -n

    Failed to access NetBT driver — NetBT may not be loaded

    [Aaron Margosis]  Seems to be a LUA bug in XP and 2003:


    Probably inadvertent — those operations should work for members of the Network Configuration Operators group, but they don’t.

  33. Why not install software under a user dedicated to that software? I know in some cases this is a bit much, however this could apply that when you install software all files and registry keys created are owned by that user. Rolling back system changes can be done similarly to removing a user and all their associated files & keys.

  34. Hi,

    Can I get a copy of your tool. When I try to download, it is giving page cannot be found.



    E-mail: dcherian@dlbassociates.com

  35. please send me the link to download LUA tool

    [Aaron Margosis]  Link to the currently published version: