Why we must (always) develop as non-admin?

Only this week we decided that our company will do a major (but good) policy change: that none of the developers will have administrative privileges for his development machine (usually VM). And this is correct timing, that I read an article in “debugging .net 2.0 applications” written by John Robbins that puts the same emphasis on this point, even more strongly.

John Robbins in his book says like this:”There is absolutely no reason at all for logging in with administrative rights to develop software”.

Actually the policy change in our company was triggered by some other problem: developers had administrative privileges in one the development (test) servers. This is even more dangerous and this is a point that anyone should ever look in to first. It is more dangerous for the developers (or for that matter tester or anyone who belongs to the project) to have administrative privileges in the development or test server. If the tester has administrative privileges he can no way ensure that the application runs as expected for the less privileged account. The same thing goes for developers.

If the developer has administrative privileges in their machine by default he assumes that everyone (user) runs the application with same administrative rights and by this way he overlooks some important bug that is potentially a ticking bomb that resides with in the application until discovered – that may even lead to architectural change in later point of development stage.

For example, an application, assume it as ASP.NET application, wants to write and read some binary assets from a shared network directory. The application runs in Windows Integrated Authentication. A shared network directory is created in a different server other than the development server where the application runs. Non-Functional requirement says that only a service account should be able to access this shared network directory. The developer, to achieve this non functional requirement must develop a program that authenticates the service account by using configured password. Somehow that developer over looked this requirement and totally forgot this authentication part.

For some weird reason, which often happens in some small or developing IT companies, some key developers of the project had admin rights on the machine where this shared network directory is created. Now what happens? The developer develops and tests the application on his local machine for which he has admin rights. The program works fine. He deploys the application to the development server to test this functionality. Since this user has admin privileges on the shared network machine and since the application uses windows integrated authentication his program works fine in the development server too.

Now the manager who often acts as QA in this small IT Company wants to test (!) this new functionality developed by his key programmer. Unfortunately since the manger was using this shared machine for something else previously had admin rights. That’s the end of the story.

eWeek points out like this:
Any gains that an organization may realize by giving its users Administrator or Power User rights are quickly offset by problems, as these rights enable users to make what are often bad decisions.

Other than development benefits, barring users from gaining administrative access will restrict their ability to install malicious or unwanted software and this tightens the security.

For further reading:
1. http://nonadmin.editme.com
2. http://blogs.msdn.com/aaron_margosis
3. eWeek