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

re: What is a "LUA Bug"? (And what isn't a LUA bug?)

Deepu Cherian — Thu, 21 May 2009 20:58:18 GMT

please send me the link to download LUA tool

[Aaron Margosis] Link to the currently published version:

http://blogs.msdn.com/aaron_margosis/archive/2008/11/06/lua-buglight-2-0-second-preview.aspx

Can I get a copy of version 1.0 of LUA bug tool

Deepu Cherian — Thu, 21 May 2009 20:57:50 GMT

Hi,

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

Thanks

Deepu

E-mail: dcherian@dlbassociates.com

Registry Keys ownership...

Richard Jenniss — Sun, 21 Sep 2008 06:53:27 GMT

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.

re: What is a "LUA Bug"? (And what isn't a LUA bug?)

Henning Plumeyer — Fri, 22 Feb 2008 16:37:28 GMT

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:

http://support.microsoft.com/kb/888373

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

nbtstat: LUA Bug?

Henning Plumeyer — Thu, 08 Nov 2007 21:59:45 GMT

I have tried on Windows XP and Server 2003 only.

nbtstat: LUA Bug?

Henning Plumeyer — Wed, 07 Nov 2007 20:24:06 GMT

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.

Changing access control on folders vs. files

Aaron Margosis' WebLog — Fri, 16 Feb 2007 05:14:32 GMT

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

re: What is a "LUA Bug"? (And what isn't a LUA bug?)

David Williams — Tue, 30 Jan 2007 18:02:30 GMT

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:\Users\Public). 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 Settings\All Users\Application Data and can be looked up using CSIDL_COMMON_APPDATA)?

David: There isn't a C:\Public, but there is a C:\Users\Public. 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.

HTH

-- Aaron

Common_AppData is Readonly

Mike O'Grady — Wed, 03 Jan 2007 18:16:09 GMT

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 Settings\All Users\Application Data\Company\Application. 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 Users\Application 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.

HTH

-- Aaron

re: What is a "LUA Bug"? (And what isn't a LUA bug?)

John Bokma — Sun, 17 Dec 2006 19:03:22 GMT

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.