Should developers have administrator permissions on their PC or is giving them power user access sufficient?
Some comments:
We are team of 5 developers and build web applications
If you invert the question I think it becomes easier to answer; should we remove administrator permissions from developers? What is the gain?
But actually, I think the answer depends on your context, your environment. Small startup will have a different answer to ISO-certified government agency.
Yes and no.
Yes, it saves lots of time bothering system support.
No, your users don't have it so don't count on it.
We develop with admin permissions and test without. Which works out right.
It depends on the developer skills and whether s/he is a consultant or not.
I think it's reasonable that a seasoned and trustworthy developer has the rights to do whatever s/he wants with her/his PC as long as it doesn't harm her/his productivity.
Developers should have full and total control of the machine they are using. Most debugging tools require admin permissions in order to hook into the runtime of the application they are building.
Further, devs frequently download and try new things. Adding additional steps such as needing a network admin to come by and install something for them simply frustrates the dev and will quickly make life hell for the network ops person.
That said, they should be an admin on THEIR box, not the network.
Wow, this question is certainly going to open up to some interesting answers. In reply I quote the oft used - 'It Depends' :)
In small companies this might just be simply a matter of being pragmatic. The developers are also likely to be the most technically adept, so it makes sense for them to adminster their own machines.
Personally, I'm a fan of the "admin account" which can be used when necessary - i.e. "Run As.." (I noticed this approach was very similar in principal to UAC later on).
If you are developing desktop software it's not a bad idea for developers to work within the confines that their end user's will experience - i.e. limited or restricted rights. If you build the software under limited rights, it's a good chance that you'll hit the same problems your target users would face given the same set of permissions.
Having said that, if you have a good testing lab and/or a decent QA team this might be a moot point - especially if you have a half decent ALM practice.
So finally - I develop without UAC, mainly because I trust myself and my skills. In a team environment, I'd put it to a vote. In larger organizations you might not have this freedom.. The Enterprise Admins often have the final say :)
It takes a lot more discipline to write good code than to use a PC safely. If your developers can't be trusted with admin rights then your project is so screwed that I cannot imagine your group succeeding at even a simple task.
Yes, but they need to be aware of the limitations that their users will face when running software in a more limited environment. Developers should have easy access to "typical" environments with limited resources and permissions. In the past I have incorporated deploying builds to one of these "typical" systems (often a VM on my own workstation) as part of the build process, so that I could always get a quick feel for how the software worked on an end-user's machine.
Programmers also have a responsibility to know the hard-and-fast rules of writing software for non-admin users. They should know exactly which system resources they are always allowed (or forbidden) to access. They should know the APIs that are used to acquire these resources.
"It works on my machine" is never an excuse!
You can answer this in two ways. Yes and no, or it depends. -- Can I be more vague....
It depends if it is required for them to do their job. If it is then grant them administrative powers over their computer. If not then don't. Not all software development requires an engineer to have admin rights.
Yes and no depends on your view. Some engineers view their computer as their domain and they are the rules of their domain. Others don't want the responsibility.
I have worked at one company where I did not have admin rights and whenever I needed to do something that required admin rights I had to call the help desk and they granted me temp admin rights until I rebooted. This was a pain at times, but that was the way it was so I lived with it. I have also worked at places that I have full admin rights to my computer. This was great except for the time I installed some software that hosed the OS and had to take my computer to the help desk and have them re-image the hard drive....
I personally feel that an engineer should have admin rights to their computer, but with the understanding that if they screw it up then a new baseline image can be reloaded and they will lose anything that was done since the original baseline. I don't believe that everyone in a company should have admin rights to their computer however. Accounting, administrative assistants, and other departments don't really have a need to have those rights so they should not be granted.
Local admin yes, for all of the reasons stated above. Network admin no, because they will inevitably be drawn into network administration tasks because "they can". Devs should be developing. Network administration is an entirely different job.
The answer is 'Yes'. Developers will need to frig with system configurations to test items, install software (if nothing else, to test the installation process of whatever they happen to be developing), poke about the registry and run software that will not work properly without admin privileges (just to list a few items). There are a host of other tasks integral to development work that require administration privileges to do.
Bearing in mind that development staff do not necessarily have root access to production systems, admin rights on a local PC does not significantly compromise security of production systems. There is almost no legitimate operational reason for restricting admin access to local PC's for staff that need it to do their job.
However, the most important reason to provide administrative access is that setting up a compromised or second rate development environment sends a message to your development staff:
'We value your work so little that we are prepared to significantly compromise your ability to do your job for no good reason. In fact, we are quite happy to do this to cover our own arse, pander to the whims of petty bureaucracy or because we simply can't be bothered. That's just the best case. The worst case is that we're really the type of control freaks that view it as our perogative to tell you how to do your job and what you do or don't need to do it. Make do with what you're given and be grateful that you've got a job at all.'
Generally, providing a second-rate (let alone fundamentally flawed) work environment for development staff is a recipe for the natural consequences of pissing off your staff - inability to retain competent people, high staff turnover, poor morale and poor quality delivery. Going out of your way to do so - particularly if there's an overtone of pandering to bureaucratic whim - is just irresponsible.
Bear in mind that your staff turnover doesn't just incur costs of replacing the staff. The most serious cost of staff turnover is that most of the ones that stick around will be the deadwood that can't get a better job. Over time this degrades the capabilities of the departments affected. If your industry is sufficiently close you can also find yourself getting a reputation.
One point to note is that administrative privileges are far less of an issue for development on unix-oid or mainframe systems than it is on Windows. On these platforms a user can do far more in their own domain without needing system-wide permissions. You will probably still want root or sudo access for developers, but not having this will get underfoot much less often. This flexibility is a significant but lesser known reason for the continuing popularity of unix-derived operating systems in Computer Science schools.
If by "their PC" you mean THEIR PC, well .. i think the answer is obvious.
Developers normally need to do things that the average person wouldn't, and so should normally have administrator accounts. Making them hop through awkward hoops wastes their time and demoralizes them. There may be exceptions in high-security situations, but if you can't trust somebody with an admin account you sure can't trust their code.
They should also have an available account of the same permission as their users (more than one account if the pool of users has different permission statuses). Otherwise, they may just develop something cool, deploy it, and then find it won't work for the users.
There are also too many ways to screw up computers with admin accounts (yes, I've done it). The IT department needs a policy that they will re-image a developer's computer if they can't fix it quickly. At one place I contracted at, I had to sign a copy of that policy to get my admin account.
This is a pretty Windows-specific answer. In Linux and other Unix-y systems, developers can more often get by with user accounts only, often don't need another account for test (if they've got an account they can sudo with, they do know when they're using the sudo, but they may need one with the same group permissions), and can do incredible amounts of damage to the OS very easily, so the same IT policy is necessary.
As a systems admin I'm all for developers having local admin rights on their workstations. When possible, it's not a bad idea to do most things with a standard 'user' level account and then use another 'admin' account to make changes, install apps etc. Often you can sudo or runas to accomplish what you want without even logging out. It's also helpful to remind us of what security hurtles the end-users will have to jump through when releasing to production.
On a side note it's also advisable to have a [clean] system or VM(s) so that you can test things properly and not get into the "it looks/works fine on my system" scenario due to system tweaking.
Absolutely! How else would I install the download manager to download movies at night?
Sometimes developers really need to install things or change something in the system to test out some idea. It will be impossible if you have to call the admin each time you need to change something.
I also have my personal observation that some admins tend to screw tight all that is possible in order to make even little things depend on them on a daily basis thus... what, securing their job? pissing off the other users? Have no answer. But common sense is not seen here.
Last time there was a problem with my PC I took an active part in restoring the system, making some suggestions working in the team with the admin, or so i thought... Admin turned to be very angry and accused me of trying to teach him or redefine the rules. I suppose it was just his ego as he was not seen that cool in our room among other colleagues.
First of all, Power User is basically an administrator - so "limiting" a user to Power User does not provide any increase in security to the system - you might as well be administrator.
Second, of course a developer needs administrative access to their developer machine (and servers and second boxes and so on) but of course noone should interactively log on as administrator during normal development or testing. Use a normal user account for this and most applications.
You seriously do not want to run [insert any browser, plugin, IM, E-mail client and so on] as an administrator.
You don't normally log onto your Linux box as root either, even if you likely have root access when you need it.
Provide the developer with a separate personal administrator account to his/her machine (domain account preferably) that is also a valid administrator on other dev/test servers and boxes that person needs administrative access to.
Utilize "run as" and in Vista+ UAC to prompt or request prompt and enter the administrative credentials for tasks and processes only when needed. PKI with smartcards or similar can greatly reduce the strain in entering credentials often.
Then audit access. This way there's traceability, and an easy way to find out who is using the terminal services sessions on a particular dev/test server you have to access right now...
Granted, there's definitely development work that will never require local administrator privileges - like most web development where deployment is tested against a separate server or virtual machine and where cassini or whatever is used for local debugging actually runs well as a normal user.
No one on Windows XP should be using an administrator account for day-to-day use, and in Vista if you must be an administrator at least have UAC enabled. Especially web developers and other developers who browse the web with Internet Explorer.
What you can do is have developers use their regular user account, but give them a second account that is an administrator on their PC so they can use it as needed (Run As). I know they said web development, but for Windows development your software should be tested using a regular user account, not as an administrator.
I work primarily in the *nix world and the standard model there is for developers to work in a normal, non-privileged user account with the ability (via sudo or su) to escalate to admin privileges as/when necessary.
I'm not sure what the equivalent Windows arrangement would be, but this is, in my experience, the ideal setup:
On the one hand, having admin rights available on demand gives the developer full power over his workstation when needed.
On the other, Windows software has a long, long history of assuming that all users have admin rights, to the point that many programs won't run for a non-admin user. Many of Windows' security issues stem directly from this implicit requirement that, in order to be able to reliably use the computer, all users must be admins. This must change and the most effective way to ensure that your software will run for non-admin users is for your developers to be running it themselves as non-admin users.
ht tp://msdn.microsoft.com/en-us/library/aa302367.aspx
In my experience, a compromise between us (coders) and them (security) is always needed. I admit (though I hate to), there is merit in the Microsoft article above. As I have been a programmer for years, I have experienced the pain where I needed to just install a different debugger, just to get annoyed I can't. It forced me to think creatively in how to get my job done. After years of battling our security team (and several discussions), I understand their job of having to secure all areas, including my desktop. They showed me the daily vulnerabilities that come out, even on the simplest Quicktime app. I can see their frutration everytime I want to install a quick utility or tweak my local IIS that I can cause a serious security problem. I didn't fully understand this until I saw another developer get canned. He was trying to debug and ended up shutting off Symantec only to get (and then GIVE) some virus to hundreds of people. It was a mess. In talking to the one of the "secheads" (security guys) about what happened, I could see he wanted to just say, "told you so...".
I have learned that our secheads (well, at least mine) just want to protect our company. The good news is we did find a compromise, and I can get my job done and the secheads are cool with our secure network!
Creed
The answer is, developers should have 2 machines!!
One development one that has admin rights and sufficient power, memory, screen size, and portability, and ADMIN privileges, with corporate antivirus software loaded but configurable by developer when required with autoreset policy..
One corporate one that has corporate load, policies, non-admin user privileges, etc... Developer can use this one for unit testing release mode applications as some developers have the nasty habit of doing all unit testing with administrator privileges.
Yes, Half-Life 1 (and all the related mods: counter-strike, day of defeat, etc.) need administrator rights (at least for the 1st run, I think) to work properly in Windows NT, 2000, XP, etc.
And, what kind of developer doesn't play Counter Strike at lunch time? (a crappy one for sure)
Having endured the pain of having to develop without admin rights on the machine my answer can only be yes, it's essential.
At my company, developers, engineers, and my boss (owner of the company) have local admin privilege. My boss also has network admin privilege, just in case I get hit by that wayward bus (or quit). Everyone else gets locked down.
As sysadmin, this setup has caused me a little grief from time to time, especially when unapproved software gets installed. However, coming from a developer background, I understand the need for power users to have more control over their environment and as such, am willing to put up with the occasional quirk or problem that may surface. I do perform routine backups of their workstations -- just in case.
By the way, I've had more problems with the boss tinkering around with things than with anyone else. Kind of like the old question, "Where does an elephant sit? Anywhere he wants!" But in a small firm where he is essentially the "backup" sysadmin, there isn't much choice.