Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Do Your Developers Have Local Admin Rights?

CmdrTaco posted more than 4 years ago | from the that's-why-god-invented-sandboxes dept.

Programming 605

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?"

cancel ×

605 comments

Sorry! There are no comments related to the filter you selected.

What? (1, Informative)

moogied (1175879) | more than 4 years ago | (#30606436)

We just have a development environment for them. Then once code is ready we copy the most recent backup image of the servers over, they install there, document how, and then our sys admins install. Done and done.

Re:What? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30606452)

That depends. If they use Windows, they are niggers. Niggers need admin rights to do much of anything. If they are fine white folk, then no, they can do everything as a normal Unix user.

Re:What? (1)

Knara (9377) | more than 4 years ago | (#30606612)

Article submitter was talking about local admin rights (implied on Windows) for their desktop workstations, not servers.

Re:What? (1)

tepples (727027) | more than 4 years ago | (#30606742)

I think moogied was trying to say that yes, they have local admin rights, but they're not on the production domain.

Re:What? (5, Informative)

unixguy43 (1644877) | more than 4 years ago | (#30606750)

As an admin, I've supported both types of environment. Depending on what the development project is, sometimes it's just better to allow the developers to have full admin rights in order to add compilers and other development tools required for project completion. The developers were responsible for all O/S issues related to installation of non-standard development tools, but would rely on the sysadmins for hardware support, as the service contracts were part of the corporate global service contracts. There's no easy answer on this one, and it pretty much depends on company policy around allowing admin access to non-admins. Personally, as an admin, I prefer to maintain control of what is installed on the systems under my umbrella, as it makes patching and upgrading easier when I know what's already there, and what dependencies are required.

Re:What? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30606848)

Hello friends, I'm in a bit of a bind here. You see, I have a problem with my...well, with my penis! Yes, I am slightly embarrassed to admit this, but I figure that my friends at Slashdot will be able to help me. At any rate, the problem with my penis is that every so often it gets longer and feels rigid to the touch. And, when I do touch it in this state, I get a strange, yet pleasurable, sensation. I've asked coworkers and friends about this, and they have not been able to help me. They usually giggle or laugh and say I need a cock sucker. I'm not sure what that means, and whenever I ask for clarification on cock sucker, I get sarcastic responses. So, my Slashdot friends, is there something wrong with me? Why does my penis get this way? Does anybody have a similar experience?

Yes (3, Insightful)

MyLongNickName (822545) | more than 4 years ago | (#30606438)

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 (1)

Z00L00K (682162) | more than 4 years ago | (#30606506)

I agree - without local admin rights it's close to impossible to get things done - or you will have to have a much larger IT staff.

I suspect that the same will be valid even for Windows 7.

Re:Yes (2, Insightful)

peragrin (659227) | more than 4 years ago | (#30606928)

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

I hold that windows isn't a true multi user OS until 90% of the software that runs on it can be used by a limited account. Look at any *nix. not only can you run one app under multiple users at the same time(something most windows app fail at) but all those apps are limited the privilieges of the user in question.

Yes there are apps that require different rights. but windows developers for the most part don't understand the difference between admin and limited accounts.

Maybe if they were forced to develop in such enviroments they would under the limits.

That's what sudo is for (3, Insightful)

tepples (727027) | more than 4 years ago | (#30607048)

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:Yes (2, Informative)

Opportunist (166417) | more than 4 years ago | (#30606860)

Pretty much the same experience here. Even the "maximum security" bank auditing company I used to work (and develop) for gave their devs local admin rights. At least after their admins complained that they don't get anything accomplished because they had to do something for the devs every other minute.

Instead, we got a tight rule set put in place that pretty much said that, while we do have local admin, any kind of change in the software setup of the machine (i.e. new software or new security rules, etc) required a written permission. And behold, it worked.

You needn't cast every rule in silicium. It's one of the very, very few situations where a legal system can actually do something for security.

Yes in DEV, No in TEST and PROD (4, Insightful)

garyisabusyguy (732330) | more than 4 years ago | (#30607032)

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

Yes (1)

jimbobborg (128330) | more than 4 years ago | (#30606448)

All of the places where I've worked as an Admin, I gave the developers admin rights so they could install software, but only on development systems. Don't even think about giving them on production systems. Of course, I spent quite a bit of time fixing development machines due to something these folks have done, but all production systems were updated by me.

Re:Yes (1)

Knara (9377) | more than 4 years ago | (#30606586)

Don't even think about giving them on production systems

This is really important. Dev machines are one thing, but I've found that (aside from the problems in change management that can be brought on by letting devs push changes directly to production, i.e. "it's just a little fix!") most devs have no patience for security on servers. This is fine if they're internal test boxes or VMs on their desktop machines, but unacceptable in production.

Yeah. (5, Insightful)

qoncept (599709) | more than 4 years ago | (#30606466)

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. (4, Insightful)

Aeros (668253) | more than 4 years ago | (#30607012)

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.

Local Admin (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30606470)

In previous places I have worked, the developers did not have local admin privileges on the machines on the network. We used virtual machines and test boxes that are disassociated from the network for testing and debugging, and the developers had full permissions for those machines.

You damn well should (4, Insightful)

QuoteMstr (55051) | more than 4 years ago | (#30606480)

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 (1)

QuoteMstr (55051) | more than 4 years ago | (#30606640)

Gah! My eyes! My pre-caffeine grammar!

Re:You damn well should (4, Insightful)

TheRealFixer (552803) | more than 4 years ago | (#30606698)

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 (4, Insightful)

Deorus (811828) | more than 4 years ago | (#30606898)

How can a competent developer not understand operating system concepts?

Re:You damn well should (1, Informative)

Anonymous Coward | more than 4 years ago | (#30607030)

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.

My last job's developer policy was: you have root access on your machine and you can install whatever you need to help get your work done, but if you mess up your machine, IT's solution is going to be to re-image it. (You won't lose work, because all of your work is checked in, right? And any un-checked-in in-development code can be backed up to the network first.) That way the developers get the freedom they need, and IT doesn't have to try to diagnose incompatibilities between hundreds of little third-party apps.

Re:You damn well should (3, Insightful)

ckaminski (82854) | more than 4 years ago | (#30606718)

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 (1)

qoncept (599709) | more than 4 years ago | (#30606972)

Local admin rights and permission to install anything you want aren't the same thing. I have local admin rights, but software is still installed by our desktop team, and only approved applications and versions.

Re:You damn well should (0)

Anonymous Coward | more than 4 years ago | (#30606982)

@Parent

You've clearly never written production code at a Fortune 500.

Re:You damn well should (0)

Anonymous Coward | more than 4 years ago | (#30606736)

I'd be more worried about accidentally building in dependencies on "hundreds of small programs" that won't be there in the final environment.

Re:You damn well should (3, Interesting)

Kyril (1097) | more than 4 years ago | (#30606760)

I would disagree -- the more years I spend programming the less I remember about system administration. I can do basic setup tasks, but fiddling with Active Directories and stuff like that is beyond what I care to learn and has been for what, a decade now?

At an Ancient Telecom company most folks don't have admin rights (and shouldn't) but there is an exception process developers follow, and otherwise the Company-approved packages don't need admin rights to install, plus the help desk has powers.

Re:You damn well should (1)

qoncept (599709) | more than 4 years ago | (#30606818)

Wow, what a bunch of morons. In addition to hiring people that understand you just can't do that kind of stuff, my company has controls in place to prevent it. Want to reboot a production server? You need a change ticket, approval and you're going to be doing it during the maintenance window unless it's an emergency. Gotta do it? Call it an emergency and explain yourself later. Can't? Find another job.

Re:You damn well should (1)

gestalt_n_pepper (991155) | more than 4 years ago | (#30606844)

And following that argument, is any person who can't maintain his own automobile, toilet plumbing, the airplane he flies on, or his cell phone also incompetent?

There's only so much time. I need to focus on what gives me the most return. That's not system administration.

Re:You damn well should (2, Insightful)

mcfedr (1081629) | more than 4 years ago | (#30606984)

but if a plumber cant maintain his toilet, thats when he's incompetent as a developer there are many testing scenarios when its easier/quicker/only possible by being root, and the need to install and use lots of software means needing someone else to do that gets annoying, and if a developer can't spot virus ridden software who can...

Re:You damn well should (1)

girlintraining (1395911) | more than 4 years ago | (#30606896)

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.

Must be nice, being able to pick and choose what jobs you take. Unfortunately, most people here don't have that luxury.

Re:You damn well should (1)

firl (907479) | more than 4 years ago | (#30606904)

Yeah, I agree completely. As a developer, I also have to manage deployments to the point of where I have administration rights on all of staging, and then during deployments I have admin rights on production also. to caveat it all, some developers the company has hired has no idea beyond the language they were hired to do; so for them to have admin rights has been a detriment to our tech team requiring rebuilds of their laptops several times

Re:You damn well should (1, Informative)

Anonymous Coward | more than 4 years ago | (#30606918)

Any developer who can't competently administer his own machine is incompetent. The kind of rigorous thinking required is identical.

I agree that developers should have local admin privileges, but I think this relies on them knowing their limits, and I don't believe that they need to be competent at administering their machines.

As an example, most of the code I develop runs on Solaris (with which I'm pretty intimately familiar) but I do most of my day-to-day work in Windows. I recently had problems VPN-ing into work (on Windows) and just about tracked it down to Kerio, the software firewall that we use. I was completely happy troubleshooting this far, because I understand our VPN's network flows, but troubleshooting Kerio was beyond me - I don't even know what diagnostics I can get. I passed it to our IT Support team and they investigated.

Does the fact that I can't troubleshoot obscure bits of software that I don't develop make me an incompetent developer? Isn't troubleshooting these types of problems what we have an IT Support team for?

Re:You damn well should (0)

Anonymous Coward | more than 4 years ago | (#30606948)

There's a difference between "can't" and "doesn't care enough to". Developers and sys admins have different priorities. Most developers never want to patch their boxes for a variety of reasons (don't want to reboot, don't think they need to care about patches, etc). Most developers don't want to run anti-virus because it makes things slower. Then these guys call IT on Saturday because their box has become unusable because it has has a dozen viruses and spyware and it's so slow they can't do anything and they have a deadline.

I don't think there's a definite correlation between the quality of a developer's code and their sys admin prowess.

Give developers a lab and firewall the hell out of it. Let them basically do whatever they want in there, but be prepared to help them clean up the mess occasionally when someone brings a virus in that takes out every machine. Or get a job at a Unix shop. :)

If you let your developers have admin rights in your production environment, you're a moron. They simply don't give a damn about security (and -- why should they? They're not paid or trained to be security experts (well, unless you work at a security software company :-/)). And they'll make changes there that will never get tracked by change control.

Re:You damn well should (4, Interesting)

nine-times (778537) | more than 4 years ago | (#30606998)

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

As an IT person who has supported developers, that makes me think that I've only met... like... 2 competent developers ever. Almost every developer thought he could administer his own machine, but very few did a good job at it.

As I see it (and maybe this is BS, but I'm saying it anyway), part of the problem is an issue of mentality. Developers seem to want to think about what *should* happen. Like "Oh, well installing this *shouldn't* make a difference. Changing this setting *shouldn't* make a difference." As though computers all make sense and work the way they're supposed to. In my years of doing support, I've come to the opinion that this is a very bad support mindset. Computers almost need to be treated as magical boxes possessed by evil spirits which might stop working if you anger the computer gods.

And I know, if you're a developer that probably sounds utterly silly and you think I'm a bad support guy. But you see, that's my whole point. Developers tend to have a different mindset. Computer stuff breaks all the time for no reason. Hard drives die, motherboards get fried, and monitors burn out. Sometimes enabling a setting will break your computer in some completely unrelated way. Yeah, yeah, there's a valid scientific reason. If I had access to the source code and I was a master programmer and I had all the time in the world, I could probably figure out exactly what was going on and fix it for real. But for my purposes, I just need the thing to work right now so my user can get back to work. For my purposes, for right now, it's good enough to assume that enabling the setting upsets evil spirits and angers the computer gods. It means "leave that setting alone."

It seems like every developer/administrator I've met wants to ague with that. They want to say, "But that setting *shouldn't* make a difference. Computers only do what they're programmed to do, so I just have to reprogram it right now." All that may be true, but as the support guy, you don't always have time like that. Sometimes you just have to blame the computer gods and move on.

Re:You damn well should (2, Insightful)

gemada (974357) | more than 4 years ago | (#30607090)

because IT does not equal programming or vice-versa

Generally, yes (3, Funny)

PIPBoy3000 (619296) | more than 4 years ago | (#30606482)

We're local admins of the application servers, and a couple of us have domain admin rights. We generally haven't run into problems with this, as we have a strict policy of making fun of anyone who screws up badly. It involves Photoshop and is generally a memorable way to resolve the situation.

yes (0)

Anonymous Coward | more than 4 years ago | (#30606484)

yes I do have admin rights, I couldn't do my job without it (we do have strict anti-virus that runs at 50% cpu all time time min). It takes forever to get IT or data-center to process requests so without local admin rights I would get almost nothing done each day. Actually we use windows machines to develop and don't deploy on windows machines. I tried to get non-windows machines to develop (makes sense to me) but to no avail.

Yes, because I'm not a masochist (2, Insightful)

Knara (9377) | more than 4 years ago | (#30606486)

In the Windows world you can override other things using GPOs, but it's too much of a pain from the admin side (I've found, as have my coworkers over the years) to try and lock down developer machines by removing local admin rights. I've got better things to do than schedule up a time to install things via an account with local admin rights every time something new comes along for them.

The flip side is that they have greater responsibility for maintaining their desktop/laptop systems. If it gets screwed up enough, they know they're getting the thing re-imaged with the company standard desktop image and will need to reinstall their tools they use for their personal dev environment.

Works out pretty well, aside form the devs that install absolutely everything they come across, "Oooh that looks cool! [installs][never uses again]". They can be a pain.

your obviously not a developer (0)

Anonymous Coward | more than 4 years ago | (#30606494)

If you dont know how to work around this issue... You dont NEED to be an administrator to debug or install. That said, it makes things really easy if you have a way of getting administrative privlidges to your developers. But thats a policy decision isnt it.

virtualization (1)

markybob (802458) | more than 4 years ago | (#30606524)

this is what desktop virtualization is *for*. use vmware workstation or virtualbox and test away!

Re:virtualization (1)

Panaflex (13191) | more than 4 years ago | (#30606726)

Whoa there, pardner!

That's fine for web apps, desktop apps, etc - but generally VM's have a big I/O slowdown (db's, server software, high disk usage) and aren't even usable for graphics/game development. Know your target!

That said, I love VM's and use it all the time - especially for kernel development - but it's not a catch-all solution!

Not everything is perfectly virtualized (1)

tepples (727027) | more than 4 years ago | (#30606850)

this is what desktop virtualization is *for*. use vmware workstation or virtualbox and test away!

And then the program fails because it can't see hardware that the VM doesn't properly virtualize, such as USB devices or 3D capabilities of the video card in low-end VM software. High-end VM software, which can virtualize these devices, is nearly as expensive per seat as a nettop, and the nettop comes with a free copy of Windows anyway.

Re:virtualization (1, Insightful)

RingDev (879105) | more than 4 years ago | (#30607112)

Just what I want to do... Run 3 IDEs, a SQL authoring tool and database explorer, a web browser with 5 tabs, fiddler and other debugging tools, all inside of a VM running on a 3+ year old 32-bit computer with 3 gigs of memory.

-Rick

Multiple machines, KVM. (0)

Anonymous Coward | more than 4 years ago | (#30606532)

The way ive always had it set up even in troubleshooting environments is a corporate workstation , and a test-bed system. The corporate system was hooked up like ever other drone box out there, harsh lockdowns and limited permissions, set up with email and the slew of corporate software, then KVM switched to a test box, that was basically free reign - including changing hardware configs, the only regulation was asking the IT guy for a specific make of NIC, or a re-imaged HDD to swap out.

Is this even an issue anymore? (1)

grasshoppa (657393) | more than 4 years ago | (#30606544)

You setup a development environment, which is at worst firewalled off from the production network, but ideally completely isolated. Then give the developers full reign to do as they need to do get the job done.

Re:Is this even an issue anymore? (1)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30606618)

Yeah, but then you have to keep a closer eye on what they install on the dev machine and make sure that it doesn't affect the application. If the app requires the software change on the server, they have to communicate that to those who control the servers. There are some tools that make sense in dev, that should never be put live.

This is how we do it (0)

bogaboga (793279) | more than 4 years ago | (#30606552)

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?'

I work for a major insurance company. We work as a team with external personnel. There is always tension and in most cases, their personnel of comparable rank to ours earn more, appear to have more power over what we can or cannot do.

yes (1)

PixetaledPikachu (1007305) | more than 4 years ago | (#30606558)

Mine yes. And since the dev environment resides physically on the same network of our production (separated by firewall), our server admins also have local admins to those machines. Software provisions are provided by the server admins, and we strictly monitor installed application on those servers by using software asset management tools. Testing is done not on the dev environment, but on another batch of servers specifically used for UATs, Developers has no local admin right on UAT environment.

Hell no. (0, Offtopic)

Jethro (14165) | more than 4 years ago | (#30606574)

HELL no.

One of my first gigs, the Rock Star Developers had admin rights. They'd pretty much do whatever they friggin wanted. And guess who got to blame when they screwed up? Yup, the sysadmin. Namely, me.

They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory. Not tell anyone, nothing. One time they enabled an rsync script that pretty much overwrote a week's worth of work. And who got blamed? The sysadmin, for not making it impossible for that script to work anymore. Or something. It was crazy.

So basically, yes, it's an accountability thing. If I'm responsible for these machines, then I'm in charge. Period.

Re:Hell no. (3, Insightful)

JohnFluxx (413620) | more than 4 years ago | (#30606684)

What has that got to do with LOCAL admin rights?

Conflict of interests (2, Insightful)

node159 (636992) | more than 4 years ago | (#30606728)

LOL! Giving developers admin access to production machines is like giving grenades to babies, its only a matter of time.

Ultimately it comes down to a conflict of interest between developers who's interest is to changes things (new features, new version, etc) and admins who's interest is not to change things (SLA's, guaranteed uptime, don't touch a working system).

If this conflict is not properly balanced (dev's with fingers in production, admins controlling the dev environment), you will have problems and usually ends up being a very costly mistake.

Re:Conflict of interests (3, Insightful)

node159 (636992) | more than 4 years ago | (#30606874)

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'.

Re:Hell no. (1)

ceebee (125986) | more than 4 years ago | (#30606732)

The OP asked about LOCAL admin rights. Nothing to do with rebooting servers.

Re:Hell no. (1)

Delkster (820935) | more than 4 years ago | (#30606752)

They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory. Not tell anyone, nothing. One time they enabled an rsync script that pretty much overwrote a week's worth of work. And who got blamed? The sysadmin, for not making it impossible for that script to work anymore.

That's not exactly about local admin rights. I understood the original question was about admin rights to the developers' workstations, not servers. That's a whole different matter.

Personally, I'd hate not being able to use the tools I need on my local machine to complete the job just because someone's being a control freak. (Not referring to you but to those who would deny developers local admin privileges to their workstations.)

Re:Hell no. (1)

Nerdfest (867930) | more than 4 years ago | (#30606810)

Losing a weeks worth of work has very little to do with a rogue rsync script and a whole lot to do with a lack of backups.

Re:Hell no. (1)

iSzabo (1392353) | more than 4 years ago | (#30606822)

You make a good point about developers having admin power on production machines; which could be extended to showing (one reason) why dev boxes should not be running production code (there was an article a while ago about testing on production boxes that would be relevant.)

Do you feel the same way about developers having admin rights on their development workstations (which I think is what others are commenting about)?

Re:Hell no. (1)

istartedi (132515) | more than 4 years ago | (#30606882)

Oh man, it sounds like there was no clear separation of departments there. I thought I had problems!

Some people have "admin sensibility" and some don't. I know I don't, so when somebody asked me if I wanted root on some box, I always said "NO!".

I knew there was no upside to me having root on a server. The one or two guys who had assumed the role of admin, and were comfortable doing it, it was easier to ask them for things. If it was a stupid idea for the server, they'd reject it. They wouldn't fat-finger some command, because they did it all the time. It was their specialty.

OTOH, you'd have to pry admin on my workstation from my cold dead hands. I could and did occasionaly crash that box; but the damage was limited to the work that wasn't checked in and my time spent rebuilding the box.

Ubiquitous in the mega crops (1)

node159 (636992) | more than 4 years ago | (#30606576)

Having worked in various mega corps, admin privileges for developers seems to be ubiquitous. It seems ironic that most development tools do not adhere to best practices in this regard.

But I'm not complaining, its nice to have full control of the machine, even if it always comes with the caveat 'you break it, the only support you get is a re-imaging'. At my current company this standoffish behavior has resulted in the developers running whatever OS they desire, much to the chagrin of infrastructure :).

Yes (1)

blai (1380673) | more than 4 years ago | (#30606580)

We trust our developers as much as we trust our admins. Actually, I trust our developers more than our admins, but the admins already have the highest privilege.

Yes (3, Interesting)

Alpha830RulZ (939527) | more than 4 years ago | (#30606590)

We maintain a development network and a QA network. The dev and QA teams have admin on the server machines in these networks. This is useful/necessary because we are constantly spinning up and tearing down virtual machines for various scenarios. Devs have local admin on their workstations. In general this has worked fine, except for one moron who used the privilege to turn off her virus scanning.

Production is subject to more structured control in theory, but in practice, I and another couple of guys have /sudo/root on the prod machines, because our corporate admins don't want to learn enough about the software to be useful. So much for PCI...

Yes (1)

mrian84 (1316749) | more than 4 years ago | (#30606632)

I cannot imagine a developer that does not have Admin rights on his machine. Virtualization is a bit frustrating unless you have very powerful machines.

All users had it for a time... (0)

Anonymous Coward | more than 4 years ago | (#30606634)

When I first started working where I work now, virtually every use had local admin rights and there was no web filtering. I brought these issues to a quick halt but I have no idea how my boss (at the time it would be a 1 man IT shop, just him) managed to hold it all together.

Not on any test systems (0)

Anonymous Coward | more than 4 years ago | (#30606700)

One of the problems I always run into is programs that require admin privileges to run. Not just install but to actually run properly. This is from the developers always having admin access and never actually testing under a user account. Things have gotten better over the years but there is still stuff out there that tries to pull this crap.

In some companies (1)

maroberts (15852) | more than 4 years ago | (#30606708)

Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins.

Under no circumstances (1)

nsd2142 (1174201) | more than 4 years ago | (#30606710)

Under no circumstances should any developer in any organization today have corporate production administrative rights. Its simply not needed. As a developer and a security specialist, there's a lot of ways to get by this. First, you can create an isolated domain in a development environment, or even create a production domain that they can have admin rights to - other than the corporate production domain. Adding developers to the production administrative group is dangerous and all too often leads to problems. Just a few weeks ago at a friends company, a developer went into MS DNS and wanted to change a DNS entry, and ended up deleting several entries that brought down the Exchange server. At that same company a few months back, another developer wanted to add a static entry in DHCP but accidently deleted a scope that brought down a production site. There's just too much freedom for error.

Re:Under no circumstances (2, Insightful)

bigstrat2003 (1058574) | more than 4 years ago | (#30606846)

The key word was local. He wants to know if he should give his developers admin rights on their machine, not to the entire network like you're talking about.

Re:Under no circumstances (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#30606858)

The author said LOCAL admin rights -- not network rights.

Re:Under no circumstances (1)

tepples (727027) | more than 4 years ago | (#30606916)

Under no circumstances should any developer in any organization today have corporate production administrative rights.

Other than perhaps a sufficiently small organization [wikipedia.org] , right?

I give developers admin rights (1)

citking (551907) | more than 4 years ago | (#30606730)

I give them admin rights with the agreement that, if they mess something up on their computer, they are on my schedule to be fixed (i.e., when it is convenient for me, not for them). So far I haven't had any issues whatsoever. Then again, we are a pretty small department.

My personal thoughts on the matter are simple: If the IT staff feels they can trust someone with local admin rights then that person should have them if necessary. If that person messes something up, even if it is unintentional (malware, deletes the boot.ini file, etc.) then they lose the privilege.

Yes (1)

pmontra (738736) | more than 4 years ago | (#30606740)

Yes at every company I worked at (150 to 50k employees). One large company had a developers and non-developers environment, both without admin rights but developers could ask permanent admin rights if they could demonstrate that it was required by their job. All developers asked their bosses, bosses did the paperwork and developers got admin rights. Not sure that everybody really needed it as most of us didn't write a single line of code but actually managed contractors that did the job using their company's pcs. For sure we enjoyed the ability to install whatever we wanted on our notebooks that often were our home computers too. By the way, guys with admin rights had to fix of anything going wrong with their pc because requests for assistance would be billed to the budget of the company unit they belonged to.

You mean the root password? (0, Offtopic)

Nicolas MONNET (4727) | more than 4 years ago | (#30606756)

Me I just overwrote the Windows disk with a fresh Linux install of my choosing. I got to pick the root password.

Re:You mean the root password? (1)

GiovanniZero (1006365) | more than 4 years ago | (#30606826)

They're writing windows software. That may make your strategy a little more difficult. Also, most large companies have a problem with you installing your own OS on company computers...

Virtualization is your Friend (5, Interesting)

wwwillem (253720) | more than 4 years ago | (#30606768)

In modern times, I would give them no admin rights on the box itself, but you could provide virtual machines for them on which they can do whatever they want. The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.

I've done many audits and project plans on this topic in the past, and the issue is always that developers are split personalities: on the one hand they are standard corporate citizens that need email, calendar and word, which must be rock solid and therefore IT controlled, on the other hand they do their development work that requires freedom over their box. In the past the best solution was always to give them two PCs (or a thin client for the standard desktop work), but today I would solve this all through virtual machines.
 

I'm of two minds (3, Interesting)

Anonymous Coward | more than 4 years ago | (#30606808)

On one hand, yeah, of course developers should have admin rights on the machine (i.e. local).

On the other hand, I think Windows developers should have to operate as non-admin users as much as possible so that they will realize their software won't work properly when run as a limited user. It's a perennial problem with Windows software, although it is getting better.

So, yes, they should have access to it, but discourage its use except when necessary. No running as admin all the time.

Yup! (1)

djdbass (1037730) | more than 4 years ago | (#30606828)

Developers have their machines; I have the servers. How could it be any other way?

It's Target. (5, Interesting)

girlintraining (1395911) | more than 4 years ago | (#30606838)

I'm going to end some mystery here: I am guessing the "very large corporation" is Target, a massive US-retail chain. I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes. Even Microsoft told them this was a bad idea, and you can't remove local admin from a system because it's fundamental to the security model. It was so painful watching the daily e-mails come back from amongst IT and then once every week or two see a management e-mail so loaded in buzzwords I printed it off and hung it on my cube wall next to a train wreck picture and left my coworkers to do the math. They went ahead and tried it anyway -- I've watched whole stores, departments, and even divisions just drop off the network because they rammed some security change through, didn't test it thoroughly -- and now some application is seriously wedged. The days and days of downtime are due to convincing infosecurity that there's a problem and then fixing it -- because they're autonomous to the rest of support and report directly to the board. Which means, no matter how bad they f*** up, it's your fault, not theirs, because they each think they're Agent Smith, saving the corporation from the disorder of computational devices. *face palm*

I feel your pain. I do.

The sad part is, this isn't just that corporation: It's most Fortune 500 companies. Management is so far removed from the IT process that the only input they get is from external sources: Trade magazines and consultants. This, of course, ends in tears. These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved. I don't know which trade magazine published this idea -- but when I find him, I'm going to end him. Again, not a problem specific to that company -- it's representative of what everyone finds in the field today.

Since corporations with this level of brain damage inevitably give developers underpowered systems, here's your solution: Cannibalize another system, make sure you've got a few extra GB of RAM, and install an virtual machine, then do all your development within that environment. Site licensing is a wonderful thing. Just don't ever join it to the domain and shuffle your test files in and out via a temporary share. Even better, find a standalone system and use that for development so corporate can have their ridiculous security on one system, and you have an unencumbered development platform to develop for and transfer completed work back to the main system.

It's stupid, and you should never have had to do it. But then, what about working for a large corporation is ever simple? So many people trying to ensure they're a crucial part of the business, so few who actually give a damn about it...

"Standardization" (4, Insightful)

Nerdfest (867930) | more than 4 years ago | (#30606842)

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.

It depends.... (1)

cts5678 (1383735) | more than 4 years ago | (#30606856)

On their personal laptops, yes they do. On servers or laptops used as test machines, no. Think about the security concepts of least needed access and separation of duties. On their personal laptops, they may have a need for being able to quickly and freely do certain things. But once you get to anything approaching production, they need to be locked down.

Yes (0)

Anonymous Coward | more than 4 years ago | (#30606884)

Yes

Dev verse Production (1)

TechHSV (864317) | more than 4 years ago | (#30606888)

Give them admin access to machines on the dev network, but not on the production side. Development shouldn't happen on the production network. Many developers don't realize that when on the production network they can take down the entire network by downloading some crazy app or better yet screwing up code that floods the network. Setup a lab network behind a firewall, then allow ssh traffic and maybe a few other ports to allow controlled remote access. If the developers screw something up, it just takes down their lab network.

Another example of how r-tarded management is now (1)

Kungpaoshizi (1660615) | more than 4 years ago | (#30606894)

The international company I'm at, was talking about taking it further than this, and removing admin rights from the IT staff... Yes, I believe managment degrees need to be a Masters or PHD ABOVE what they know, not a degree to be in charge of what they don't know. Right now it's like "goto college for 2 years and qualify to be the General of our armies" Another pitfall of a truly ignorant society.

What it REALLY comes down to (5, Insightful)

Anonymous Coward | more than 4 years ago | (#30606900)

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!!!

Dev with root? (0)

Anonymous Coward | more than 4 years ago | (#30606938)

Are you insane?

yes (3, Insightful)

pak9rabid (1011935) | more than 4 years ago | (#30606944)

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

Local,yes. (1)

RingDev (879105) | more than 4 years ago | (#30606956)

In every shop I've worked in developers have had local admin rights on their own machines, and possibly in the development environment.

I have been in 2 shops where the developer machines had been locked down as well as desktop users. But it didn't take long for that to change as the support desk was fielding dozens of issues each day from developers not being able to perform needed tasks (this was back in the PB/VB5/NT days).

But developers should never have admin rights over production hardware, OS's, or databases. Where I work now, we have free reign over the dev environment. We can do what ever we want and not tell a soul. If anyone is running production apps that hit the dev environment, it is a critical failure on that developer's part, not on the part of the person rebooting the dev box. We can change database schemes, install new apps, run windows update, all the usual stuff. From there we have a staging environment. The staging environment is slightly more locked down, we can still do almost everything we did in the dev environment, but all changes and reboots have to be communicated so that all other departments that may be deploying and testing are aware of the changes. After that is the production boxes. We do not have rights to get into these machines. We write up instructions and submit tickets to the support staff for deployments to these servers. All those deployments run on Thursday nights after a week long "train" process that involves IT managerial, tester, and power user sign off.

-Rick

Curiouser and curiouser (1)

Kisama (448505) | more than 4 years ago | (#30606964)

I work for a state agency, and surprisingly *everyone* here has local admin. This is a stark contrast from when I was enlisted, as not even Help Desk or Server Room had admin rights anymore as they had consolidated everything upchannel.

Sort of (0)

Anonymous Coward | more than 4 years ago | (#30606980)

For windows, by default no. You can programaticly acquire a local admin account, but doing so is also an opt out for a good chunk of IT support.

For linux, you almost certainly have full sudo rights for the box under your desk (and could get root trivially since you have physical control of the box).

Information Security 101 (2, Informative)

Reason58 (775044) | more than 4 years ago | (#30607004)

No one should be running an administrator-level account for day-to-day work. It's a huge security risk. If there are tasks that absolutely require administrative rights to do with no workaround (rarely) then you create an administrator account that they log in to for that task only, then log back on to their normal account.

I work in infosec (1)

Lord Ender (156273) | more than 4 years ago | (#30607006)

I'm in IT security at a large American software company. Some of the guys I work with want to remove admin rights from every system. These are the sort of guys who think the job of IT security is to make paperwork and avoid responsibility at all costs. I'm more of a developer, myself, and I have been able to keep admin rights for developers, but only after much arguing.

Euh, vmware? (1)

bomek (63323) | more than 4 years ago | (#30607024)

Why not use vmware or similar?

Developers do NOT need Admin access (1)

RaBiDFLY (38196) | more than 4 years ago | (#30607026)

Recently I've been tasked with network administration (I've been an admin for over a decade but this is not what I was hired to do).

The first thing I did was remove all local and domain administrative privileges from IT and senior Management.

The only person it effected was the IT Director, and once I made the appropriate local file permission changes it was fine.

A few weeks later he found he was missing access to one directory he needed so I logged onto the admin share c$ and gave him access. He was shocked I had remote access to view his files. This was a great boost as to why I have revoked administrator privileges from numerous people (I think I saw him breath a sigh of relief).

Anyway, the administrator access removal has not effected the IT Development team one bit. Once they have all the apps they need installed on their local workstation, and server level access configured for directory/file permissions, they're good to go about their development without a care.

Dan

Heck, with Visual Studio, its nearly required! (2, Informative)

LS1 Brains (1054672) | more than 4 years ago | (#30607028)

Who here, at some point in developing with Visual Studio, NOT seen it pop up that stupid message saying you have to run the IDE with administrator privileges for something or another?

Here's a quick link with just a few of the examples:
msdn.microsoft.com [microsoft.com]

Local admin rights? (2, Interesting)

SmallFurryCreature (593017) | more than 4 years ago | (#30607042)

Why not simply work on virtual machines? Then you know they are clean and you can have all the rights you want and still have comply with company rules.

In a lot of environments, setting up a good seperation is simply to costly in time, so you either end up with dev's with not enough rights to do their job or to many where they can endanger systems they shouldn't.

So it should not be needed to have local admin rights, but then the sysadmins got a hell of a job to setup everything so that it is not needed. Most sysadmins simply ain't capable of that, or if they are, are not given the time.

Not only developers (0)

Anonymous Coward | more than 4 years ago | (#30607064)

I work for a company of ~6500 people, and every last one of them is a local administrator. I work helpdesk, please pray for me/send me booze.

Yes : Admin on personnal workstation (1)

AwaxSlashdot (600672) | more than 4 years ago | (#30607092)

This is my 4th workplace and at all, from a 4 persons start-up to a international investment/corporate bank with a 1500 dev department, all dev had Admin rights to his own station.
In theory, you could be writing software as a simple/advanced user and the IT dept can grant you the exact rights needed to do so. BUT there is a huge amount of complex access rights involved when working on Windows using VisualStudio with no exact list of what are exactly the rights needed. MS tried to simplify the process by creating dedicated groups (like VS Developers group or Debugger Users group). At the end, most of the time, the IT dept simply grant local admin rights to every dev so they are not disturbed every 5 seconds because a very complex to trace access right is missing.

Developers Require Local Admin (1)

filesiteguy (695431) | more than 4 years ago | (#30607100)

I have eight developers who work for me, all doing Wintendo development using .net (C#, asp.net), some COM (still!) and even some cold fusion and ADABAS. For the Wintendo systems, they require local admin in order to be able to test installations of assemblies and other DLL files in "protected" areas as well as gaining access to HKLM and other needd registry hives.

Our users - around 2000 - have only normal user accounts.

How to do it right (1)

fluffernutter (1411889) | more than 4 years ago | (#30607104)

Any shop that knows what they are doing would do it this way: - dev environment for devs to monkey around with; seperate network from prod - UAT (and possibly INT) environment for dry-runs of deployments also on a separate network, also used to document said deployments - PROD, accessible only by a handful of staff who follow documentation created above

Yes, local admin but... (1)

sbeckstead (555647) | more than 4 years ago | (#30607134)

Local admin on the machine I use every day but restricted rights to the domain. Also the on the term servers we have restricted installation rights to allow deployment of our apps. Pretty standard as far as I can tell the last 3 or 4 companies I've worked for worked this way.

Programs should not need admin rights to run (1)

LuxMaker (996734) | more than 4 years ago | (#30607136)

Programs that do are just sloppy/lazy coding. Unfortunately that describes most of the code out there.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>