John Robbins' Blog

LUA, LUA, LUA

Are you running as a member of the Administrator group right now?  If so, I need you to raise your hand, hold it behind your head, and give yourself a dope slap!  There's absolutely no reason for any developer to be logged in as a member of the Administrator's group.  I've been developing as nothing more than a member of the User group for over two years.   When Vista finally works its way out of Redmond, we'll all be non-admins as default, but there's nothing stopping you from starting immediately to correctly use your computer.

 

A great case for why running as LUA (Least User Access or Least Privileged User Account depending on who you ask) is important is in a new whitepaper from Microsoft.  (Disclaimer, I was a reviewer).  The paper covers why it's good to be LUA and what are some of the practical steps you need to take to get your work done.

 

The simple fact that the nasty virus targeted at Windows relies on you being an Administrator to get their hooks in should be reason alone for you to just stop!  Since everyone reading this is a software developer that makes us technical support for friends and family.  What I've done is set everyone up as non-admins, with a 15-minute explanation as to why, and all those "come over and get rid of the viruses" or "why is my machine slow" calls have dropped to ZERO.  That alone should convince you to take the plunge.

 

As software developers, please, test your installs, if applicable, and code running as non-admins.  I recently purchased a very cool shareware utility that I liked because it could make me more productive.  The company came out with a new release yesterday with some even better functionality.  Sadly, they obviously never tested their new version running as a non-admin because it crashed or hung all over the place.  (Oddly, the previous version worked as a non-admin.  I guess they just got lucky).  Nothing ticks me off more than finding LUA bugs in an application.  It makes the developers look like complete morons.  Sorry to be harsh, but that's the reality of the situation.  Don't be a moron!  Test your application running as a non-admin!  Please, I beg of you!

 

There are numerous resources to show you how to run as a non-admin.  Start with nonadmin.editme.com as it's a wiki that consolidates all the various spots on the internet that discuss what you need to do.  Much of the content comes from Aaron Margosis, whose blog is a mandatory subscription in your RSS reader.

 

When running as a non-admin, the biggest issue you'll run into involves the Control Panel.  Unfortunately, many Control Panel applets, like my Toshiba M200 docking station applet, won't run as a non-admin.  While you can go through the hassles of starting a new instance of Explorer as an Administrator, there's an easier way.  I've not seen this mentioned anywhere, but to start a Control Panel applet in a different user account, hold down the SHIFT key and right click on the applet.  The usual context menu will now have a "Run As…" option on it so you can start the applet with different credentials.  Consider this my gift to you to start you on the path of correct computer usage.

On Feb 7 2006 12:34 PMBy jrobbins With 4 Comments

Comments (4)

  1. In the past, I've tried and stuck to it for a good long while. Then, for some reason that I can't fathom, something big goes wrong, like not being able to open Visual Studio .NET. Each time, I swear I didn't tinker with anything, but each time Windows Update had just done something major. I'm sure the kinks will be ironed out by Vista, but are there no kinks with running Automatic Windows Updates as a non-admin on XP? I really, really made a big effort to stick to this, but each time it ended up costing me dearly, in the form of VS.NET refusing to open. I started a support session with MSDN, and even they gave up and told me to repave the OS. Unfortunately, it was not a one time event.

  2. Yup. Now it has left me with the following exception whenever I try to debug my web service: The type initializer for 'System.Web.Compilation.CompilationLock' threw an exception.

  3. I have been using an limited user account for more than a year and I absolutely love the higher level of security. However, I should also point out that LUA does come with its own set of frustrations due primarily to developers overlooking the obvious and failing to test applications and tools in limited user accounts. Some of the violations (MORON ALERTS) I've run across include: Requiring CRUD access to the %ProgramFiles% folder to store a working file that should be in the %UserProfile% or %Temp% folder. Requiring write access to HKLM in the registry for what should be user settings in HKCU. Storing application-level settings in HKCU (e.g. paths to required files) that should be stored in HKLM. Requiring activation or license information during installation and storing licenses and keys in HKCU of the Administrator account and not allowing activation or licensing by limited user accounts. One specific tool vendor absolutely refused to help with activation issues and told me that they will not support non-administrative accounts. Opening registry keys with CRUD access to read a registry value. I find this one to be particularly heinous because it opens the code to potentially serious bugs and attacks. Perhaps not so surprising, the worst offender is Visual Basic 6.0 and COM/ActiveX. If you open Visual Basic and attempt to use a COM or ActiveX control for the first time in a limited user account, Visual Basic crashes consistently. The only work around is to run Visual Basic with an administrative account, drop the control onto the form (or reference the control) to allow it to register itself. From this point forward, the control works fine in a limited user account. Note that when I say register itself, I do not mean "regsvr32 control.ocx". Apparently Visual Basic or the control does something behind the scenes that requires administrative access but fails to check for errors. To help facilitate performing administrative tasks, I keep a small batch file on my desktop to run a command prompt as an administrator (runas /user:administrator cmd.exe /K title "Administrative Command Prompt"). I generally find that running Explorer as Administrator is nearly useless because Explorer will not refresh the screen when working with files. In other words, creating, moving, renaming, or deleting files has no affect on the Explorer screen unless the user manually presses F5.

Leave a Comment

Archives

Tags