Do Your Developers Have Local Admin Rights?

plover writes "I work as a developer for a Very Large American Corporation. We are not an IT company, but have a large IT organization that does a lot of internal development. In my area, we do Windows development, which includes writing and maintaining code for various services and executables. A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers. My question is: do other developers in other large companies have local admin rights to their development environment? If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?"

Comments

Yes

[MyLongNickName]

Yes. Both at the company I work for and the regional bank I developed for a couple years ago. It is impossible, IMO, to do many functions without these privileges.

Re:Yes

[mikael_j]

Having old hardware does not encourage developers to write more efficient code, it angers them and makes them disgruntled.

I'm all for test environments being constrained in terms of hardware if that's what a real-world production environment would look like, but to tell devs they need to use 17" CRT monitors running at 1024x768@72Hz attached to 1 GHz PIII systems with 512 MiB of RAM will not make them more productive (I've had worse systems thrown at me as "developer workstations" in the last two years, good luck running your IDE + debugger + test environment on that).

/Mikael

Yeah.

[qoncept]

At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.

Re:Yeah.

[Aeros]

In my current position and also the last company I worked with we had this policy in place. What they ended up doing is giving us two user accounts, one was low-level which was our regular account then a high-level that we switch to when we needed local admin rights for doing installs. Seems to work out fine and I hear alot of companies operate this way. It is a pain to switch back and forth but it satisfies all parties and I am able to get my work done.

You damn well should

[QuoteMstr]

Any developer who can't competently administer his own machine is incompetent. The kind of rigorous thinking required is identical. I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job. I've used hundreds of small programs to help me in my work, along with kernel debuggers and other tools that require administrative privileges. Having to ask for approval and installation assistance for each of them would have been impractical.

If you're worried about developers screwing up their boxes, why aren't you more worried about these developers screwing up the their code?!

Re:You damn well should

[TheRealFixer]

Any developer who can't competently administer his own machine is incompetent.

You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops. Didn't understand basic networking principles or basic OS functions and dos and don'ts. That being said, I still would give them admin rights to their own workstations. Otherwise I'd be spending my whole day installing a billion apps for them that they need to test or develop with, and that also ends up being a waste of their time having to wait for me. But I also have the expectation that they're probably going to need some additional care when they mess something up.

But admin access to production servers, absolutely not. I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.

Re:You damn well should

[ckaminski]

Because it's not a developers job to worry about day-to-day administration of their systems, and any one of those 100's of tools you download and install could be a trojan in disguise. If your software runs in an unprivileged fashion, it's less likely to cause rampant widespread damage.

And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent). Until we bash them over the heads about it.

Concern for code is appropriate, but irrelevant. Too much requires root or equivalent access in todays day and age.

Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother

Re:You damn well should

[Deorus]

How can a competent developer not understand operating system concepts?

Re:You damn well should

[Darkness404]

Thats why you do the sane thing and you know, isolate those systems. Guess what? Development boxes aren't mission critical, if 5 of them go down you just shrug and run to the local computer store and buy the components or a new system for them. Usually development systems are a bit faster than the typical workstation (you don't want http://imgs.xkcd.com/comics/compiling.png to happen do you?), but can usually be hacked together from spare parts and not maintain uniformity that is critical for the rest of them. In general, other than software development stuff, not much else should be saved on a development machine. Same with testing. The way its set up for me (and I helped design some of it) is there are three classes of machines: Development, Testing, and Typical. On development machines they usually have generic, cheap and fast hardware, nothing saved onto the computer thats important, and developers have total admin rights over it, but they are isolated on a different network. Testing machines have the same hardware as the typical machines, the typical developer does not have admin rights except to install pre-approved things, and its hooked up to a network very similar to the one the typical machines are on. This lets us test patches, new software and other things before doing a company-wide rollout. And typical machines all have identical hardware, no admin rights for the users, and are hooked up to our main network.

Re:You damn well should

[MightyMartian]

That's not an example of a developer who doesn't understand OS concepts. That's an example of a moron who should be shown the door with extreme prejudice.

Re:You damn well should

[bwcbwc]

WTF? It IS a developer's job to worry about system security from an application implementation perspective. It IS a developer's job to understand the operating system well enough to understand the best way to use the operating system's APIs and services. It IS a developer's job to understand what software is on their system, because that software could be interacting with the program they are developing. This knowledge alone makes them more competent to administer and manage their own PC than your typical COE support person. On top of that, they need the access to do their job.

1) Developers should have local admin rights on their machines
2) Apart from automated software updates for standard anti-malware and office tools, the developer should install and maintain the tools required to do their job.
3) The developer should not require access to the normal helpdesk support for issues local to their PC.

On the other hand, as posted below, there is no reason a development machine can't be isolated from the local network, or else the local admin rights can be granted to a local-only user that does not have access to the network. If your company doesn't want to provide developers with two separate computers, limit the network access to a non-admin user. Under *nix, Vista or Win 7 the developer can sudo or invoke the local admin user to install software and perform administrative tasks required for software development.

Heck you can even force developers to develop inside a virtualized environment in a VHD image, but they'll still need admin rights within the virtualized system. Your testers, even moreso.

Re:You damn well should

[Daishiman]

Because knowing OS theory doesn't make you an OS specialist dedicated to implementing good practices on production systems. Even a kernel dev might not know how to install and deploy a production system and implement all backup, user, and processing policies.

Re:You damn well should

[mcmonkey]

Wow. The scariest part of your story is people think this guy is a top performer.

Now, on the one hand, you can say he was very competent in operating his workstation. He knew how to install software. He knew how to configure said software the way he wanted. He knew how to change OS settings to make sure his software worked the way he wanted. He did all this without having to contact anyone else for support

Really? So 1) he owns the company? Or is the president or CEO? If not, why the fark should the world revolve around the way he wants his system to work?

2) Why is it a good thing he can get his system to work the way he wants, when he wants every hacker on the planet to get in to your company's systems through his laptop? And if that's not what he wants, then his software is not configured the way he wants.

Seriously, this guy is a menace. I can grab a chain saw and rip open someone's chest, that does not make me a competent heart surgeon. Yes, this guy made changes, but in no way should anyone say he is competent in operating his workstation.

Re:You damn well should

[Roogna]

And a developer that would make those choices when installing software on his machine, is -also- a developer that will leave wide open holes in the software he's developing for you. After all, he's obviously straight up lazy. So all I'm getting from this is that while he put out more LoC than your other developers, they were most likely buggy insecure junk.

Re:You damn well should

[keean]

If the developer does not understand basic computer security, then their code is probably full of the same problems. To write secure code, you have to understand security.

Re:Hell no.

[JohnFluxx]

What has that got to do with LOCAL admin rights?

"Standardization"

[Nerdfest]

Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users. A developer needs at least elevated rights on a workstation.

Re:Conflict of interests

[node159]

In addition, as a developer I NEVER want to know root passwords for production systems, as this only means two things, support calls and being on the short list for the which hunt when something enviably goes seriously wrong. There is nothing quite as cover your ass as 'I never had access'.

What it REALLY comes down to

[Anonymous Coward]

Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem. The entire design of windows is to install **** under system32 or program files when it doesn't need to be there. I remember the old days when programs ran under one directory. Easy to maintain. You know where everything is. To uninstall is simply to delete. Don't get me started on the registry. REALLY? You're telling me it's "faster" than reading a text file config. Hardly. ARE YOU HEARING ME MICROSOFT? Why the **** do you even need admin rights? YOU DON"T!!!

Re:What it REALLY comes down to

[bakuun]

Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem.

For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software. There are reasons that you want the operating system to be aware of when software is installed. One good advantage of this (in the Windows world) is the add/remove programs section under the control panel, where you can view all installed software, how large they are, and easily uninstall any of them. Another advantage (this time from linux) is system-wide updates of all installed software.

The entire design of windows is to install **** under system32 or program files when it doesn't need to be there. I remember the old days when programs ran under one directory.

Yeah, one directory, like... "Program files"? Every program installs to Program files by default, although the user is free to change this of course. How does it work in linux? Well, if you install something parts of it can go in /usr/bin, parts go in /etc, parts in /usr/lib, some in /var/.../

You know where everything is. To uninstall is simply to delete. Don't get me started on the registry. REALLY? You're telling me it's "faster" than reading a text file config. Hardly.

I don't know if it's faster - it might be, or not. It probably doesn't matter a great deal anyway - it's not like it's a lot of data. I doubt it's slower, though. The windows registry is a hierarchical system of configuration settings (with parts that are global for the machine and parts that are local to the user), and /etc is a hierarchical system of configuration settings (contained in text files)... Where's the big difference?

yes

[pak9rabid]

The entire development team where I work has full admin privileges on their local workstations. Not giving them that would be disastrous for productivity...

Yes in DEV, No in TEST and PROD

[garyisabusyguy]

It is a huge pain in the ass to do development without local admin rights.

HOWEVER, it is a huge cluster fuck to implement in PROD because your permission levels all have to be reconfigured to fit any rational security model.

I have found that denying developers local admin in the TEST environment is a good way to shake out any implementation nightmares

That's what sudo is for

[tepples]

if the developers have to develop for a multi user and limited rights user OS they will actually build software that obeys those constraints.

That's why you use an OS that has a counterpart to sudo, like Windows Vista, Windows 7, Mac OS X, or Ubuntu. You'll still get "permission denied" for apps that you develop, but you still have the right to elevate to run an installer.

Re:What?

[Javagator]

as an admin, I prefer to maintain control of what is installed on the systems

That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier, and never the twain shall meet.

Re:What?

[pixelpusher220]

actually it's usually about the manager's making *their* jobs easier. Having to explain why you need 2 machines (1 prod/1 dev) for a developer and 2 separate networks that need to be segmented and separately secured with separate configurations let alone the expense involved tends to get a big fat 'no' from mgmt. "Just do it the quickest and cheapest you can".

An Admin is well within his rights to maintain control over what is installed. Remember all the inadvertent leaks of documents because a user installed some file sharing program? That's an admin who didn't have, or wasn't allowed, adequate control over systems under his umbrella.

Developers DO need full admin rights on their dev boxes. You *really* don't want to be bothering the admin teams with "hey I need to restart IIS and/or reboot my machine" every 15 minutes if you're troubleshooting something.

the proper solution is separate networks where the developers simply can't cause significant damage by having admin rights. Unfortunately as has been said above, it's just easier to give developers admin rights on their systems without them being on separate networks from production systems.

Re:What?

[syousef]

That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier^H^H^H^H^H^HPOSSIBLE, and never the twain shall meet.

There fixed it for you.

Re:What?

[dvice_null]

"worked best for me"? I'm sorry, but isn't your job to support the others and make their work easier, not the other way around? Obviously you should make your own work more efficient, but not in the expense of the others. So are you sure your solution has not harmed anyone? "It took some getting used to" sounds like harm to me.