Developing as Non-Admin
		Home « Computers « DevBlog

Back to: Development Blog Contents

Do not develop software using an account with Administrator permissions. It's a bit tricker to develop as a non-Admin, but it's worth the effort.

I'm not sure what triggered the change, but in mid-August 2005 I finally decided to bite-the-bullet and demote my regular login so that it does not have Administrator permissions. There are many articles available that describe how software developers must not be lazy and develop using an administrative account. The simple reason for this is that you can't simulate a typical runtime environment while running as an administrator. In a professionally managed site, most software will be installed by an administrator, but it will probably run under a normal user account. Attempts to write to files and the registry during testing by an administrator may fail under a normal user account.

I should have bitten this bullet earlier, as back in the late 80s when I was an MVS style systems programmer, this lesson was rammed home when one day I accidentally compressed SYS1.LINKLIB instead of our site's concatenated SYS9.LINKLIB. The whole system slowly died and then took a whole day to repair. This spelling mistake would not have caused the disaster had I been logged on as a non-'special' user. After that, we all converted out logins to be less powerful for normal work, only going RACF 'special' via a manual command when needed.

The previous paragraph will only be meaningful to ex IBM style systems programmers.

The same principle applies in the Windows PC world, where you should perform your normal day-to-day work using a non-Admin account, only elevating your permissions when needed for some specific task. See:

Developing Software in Visual Studio .NET with Non-Administrative Privileges
by Lars Bergstrom (December 2003)
Security Concerns for Visual Basic .NET and Visual C# .NET Programmers
by Robin Reynolds-Haertle (July 2002)

Following are some tips about the problems I found after demoting myself.

NTFS Permissions

Over the previous year since my development PC was built, I had created several new folders to hold Visual Studio project, documents, spreadsheets, images and test data. All of these folders were created by an Administrator and were not writable by a non-Admin account. Under a non-Admin account, just about everything failed, I couldn't even open a VS project or save a familar Word document. An hour or so was required to carefully walk through the major folders on each hard-drive looking for inappropriate permissions and to set them to suitable new values.

I decided to not inherit permissions from the drive roots, and I manually set each major folder to a specific set of permissions like the following:

SYSTEM (Full Control)
Adminstrators Group (Full Control)
VS Developers Group (Write)
Users (Read &Execute)

My regular login is only a member of these groups: Users, VS Developers, Debugger Users. I do not like the default permissions on Windows XP Pro for the drive roots, that's why I chose to be conservative and not inherit parent permissions for my major folders and set their permissions explicitly.

NTFS Problems

I ran into some problems settings the permissions on my major folders. After a lot of heartache I eventually discovered that some 'phantom' (previously deleted) users still had permissions on some folders, then I found a few folders with incorrect owners. At one point I found I was inheriting low permissions from the root drive for a user that was not defined in the root drive permissions (a contradiction!).

I decided to 'clear' the permissions on complete folders by manually forcing the owner back to the Adminsitrators Group on all subcontainers and objects, then replacing permissions on all child objects. This 'sweeping clean' and resetting of permissions down folders finally solved my problems and created a much cleaner and neater environment. Don't let your NTFS permissions get into a jumble, I only had a small mess, but it's a good idea to audit your security settings regularly.

Once I had forced all of my major folders to have simple and sensible permissions I could return to work normally, well, mostly (read on...).

Admin Needs

Many developer tasks require Administrator privilges. Launching an MSI setup smartly asks you to enter the password for Administrator, which is quite neat and automatic. Almost every other significant task under Control Panel or Explorer to manage security requires Administrator priviliges. At first I thought it would be simple to create a shortcut to Windows Explorer with the property of 'Run with different credentials' to prompt me for a password to elevate myself, but as everyone else has found, the explorer process is a singleton and transfers control to the original instance and you never see a new Windows Explorer window open. I have not yet found a way around this.

Instead, I created a shortcut to Internet Explorer (IE) with the 'Run with different credentials' flag set. I also specified the '-e' switch to start IE in folder explorer mode, then put this shortcut on my desktop and in the quick launch bar. I use this shortcut whenever I need instant access to the system with Administrator privilges. The window starts with a weird appearance, but you can quickly navigate around and perform the required tasks.

NOTE: Changing the file system in this IE window does not seem to trigger a folder view refresh. You have to press F5 to force a refresh after changing files or folders.

Developer Problems

So far, the only significant problem found while developing as a non-Admin is that attempts to write to the 'Program Files' folder will fail. Most of my apps used my optlib library to write INI files in the current folder, which is not permitted. I changed all of my apps so that the INI file option store was placed in the 'AllUsers' folder instead of the 'Local' one. A few data files also needed their default location moved to the 'AllUsers' folder which is something like:

C:\Documents and Settings\All Users\Application Data

The .NET Framework has Environment class methods and properties to work with these standard folders that can be modified by all user accounts. The same applies to the HKCU hive in the registry. Attempts to write to HKLM will probably fail. Do the right thing and obey the logo guidelines. Developing as a non-Admin will help.

ImageComposer

Here's a weird problem: Microsoft ImageComposer 1.5 (a fabulous app which was originally bundled with FrontPage 97, 98 and 2000) cannot save GIF files under a non-Admin account. Tracing with filemon indicates that it is attempting to access these folders, even though it is running under a regular user account:

C:\Documents and Settings\Administrator\
C:\Documents and Settings\Administrator\My Documents\

An attempt to save a GIF will generate the following popup messages:

Cannot save image. Image format filter initialization failed.
Cannot write image. The disk may be full or write-protected or there may be insufficient memory.

I cannot find any registry settings or other app settings that can override this behaviour. It seems that the problem lies inside ImageComposer itself, or more likely, within the GIF image filter (wherever it is), hinting that something is accidentally not logo compliant. The only way around this seems to be to right-click the shortcut to ImageComposer and 'Run As...' an Administrator. Why this problem only occurs for GIF files is an extra mystery, as you can save as BMP and JPG files without a problem.

Back to: Development Blog Contents