Forgot your password?
typodupeerror
Programming IT

Do Your Developers Have Local Admin Rights? 605

Posted by CmdrTaco
from the that's-why-god-invented-sandboxes dept.
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?"
This discussion has been archived. No new comments can be posted.

Do Your Developers Have Local Admin Rights?

Comments Filter:
  • Yes (Score:4, Insightful)

    by MyLongNickName (822545) on Thursday December 31, 2009 @12:47PM (#30606438) Journal

    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.

    • by Z00L00K (682162)

      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: (Score:3, Insightful)

        by peragrin (659227)

        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

        • by tepples (727027) <.moc.liamg. .ta. .selppet.> on Thursday December 31, 2009 @01:20PM (#30607048) Homepage Journal

          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: (Score:3, Informative)

      by Opportunist (166417)

      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) re

    • by garyisabusyguy (732330) on Thursday December 31, 2009 @01:19PM (#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

      • Re: (Score:3, Insightful)

        by cayenne8 (626475)
        Hmm...what are these DEV, TEST and PROD environments you speak of?

        Hehee...honestly, and a LOT of this was govt work, so many (I'd dare say MOST) projects I got onto, you basically had one box they gave you, you developed on it...and when it got to a working state..voila!!

        It then became the production box.

        The lesson I learned from this? Make damned sure to order the most amount of hardware you can on a govt/DoD project, cause you likely won't get any other boxes anytime soon, even if they promise them to

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

    • by Knara (9377)

      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. (Score:5, Insightful)

    by qoncept (599709) on Thursday December 31, 2009 @12:49PM (#30606466) Homepage
    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. (Score:4, Insightful)

      by Aeros (668253) on Thursday December 31, 2009 @01:18PM (#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.
      • Re: (Score:3, Insightful)

        by Z34107 (925136)

        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.

        This seems to be what Vista's UAC is perfect for! Just type in your password when you want to install something on your limited account...

        </troll>

    • Re: (Score:3, Insightful)

      by galego (110613)
      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.

      I think there's validity to that ... for most semi-responsible developers.

      However, if you are programming with security exceptions, you are likely to develop things that have/require more security exceptions (e.g. you must be admin/dbo/supe

  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Thursday December 31, 2009 @12:49PM (#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?!

    • by TheRealFixer (552803) on Thursday December 31, 2009 @01:01PM (#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.
      • by Deorus (811828) on Thursday December 31, 2009 @01:12PM (#30606898)

        How can a competent developer not understand operating system concepts?

        • Re: (Score:3, Insightful)

          by TheRealFixer (552803)

          Because it's not their job, or their area of expertise.

          As a case in point, here's an example I dealt with a while back. One of the best developers in the company was having issues with Remote Desktop on his XP machine. He got tired of it, so he installed VNC server instead, so he could remote into it from his other workstation. And he set it up without a password, because he didn't want to be bothered to enter it every time he connected. And in order to get it to work, he disabled Windows Firewall. Oh,

          • by MightyMartian (840721) on Thursday December 31, 2009 @02:02PM (#30607702) Journal

            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.

          • by mcmonkey (96054) on Thursday December 31, 2009 @02:53PM (#30608376) Homepage

            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.

          • by Roogna (9643) on Thursday December 31, 2009 @03:34PM (#30608810)

            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: (Score:3, Insightful)

            by keean (824435)
            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: (Score:3, Insightful)

          by r7 (409657)

          How can a competent developer not understand operating system concepts?

          Operating system concepts are one thing, systems administration is quite another. Most competent engineers can install and configure software given a package management interface but few can manage a system, including their own desktop. Every instance I've known where developers had root/administrator access they regularly screwed it up.

          SA and ENG are both full time disciplines and nobody can do both well. Sure they think they can, but auditing their systems/code tells a different story.

          And therein lies

        • Re: (Score:3, Insightful)

          by kbielefe (606566)

          How can a competent developer not understand operating system concepts?

          There's a difference between aptitude and practical skills. I know more about the software for helicopters than pretty much every pilot, but that still doesn't mean I can safely fly one. Nor does it mean I'm incapable of safely flying one. I just haven't learned the practical skills.

          Same goes for system administration, especially if like me you use a different operating system at home than at work, and are developing for a third, embedded, operating system. Sure, I can and do install the software I need

        • by Daishiman (698845) on Thursday December 31, 2009 @02:19PM (#30607968)
          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: (Score:3, Informative)

        by AnodeCathode (787159)

        We allowed our developers to have local admin access. In exchange, their machines were located on a separate VLAN and all communication routed through an internal firewall. This allowed these uncontrolled machines to do what the developers wanted, but allowed us to easily shut them down in an outbreak. It also gave the developers easy access to logging their traffic and understanding exactly what would be required to have applications run in a restricted environment.

        For production systems, the developers

      • by Savage-Rabbit (308260) on Thursday December 31, 2009 @01:43PM (#30607404)

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

        IMHO:

        • Development should be done using dedicated development systems that replicate the production environment. I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.
        • The development machine-pool should have it's own admin who's **only** role it is to service those development machines along with the version control/collaboration suite/bug tracking/etc... servers and development should never be done on live systems if it can be avoided. You need dedicated admins for the development machines because otherwise dozens of developers with root access will turn them into a godawful mess in no time flat.
        • Developers should have root access to their own personal workstations/laptops.
        • Developers should not have root access to development systems.
        • Developers should never, ever, ever have root access to production systems.

        I have worked in various places that had strategies ragning from what I just described and to developing-on/deploying-to live productions systems (with all the irate customers due to regular downtime caused by unexpected bugs which that entails). One place I worked at didn't allow developers admin rights on what development systems they had, they were too cheap to cough up for enough development machines and whenever (rarely) they did overcome their sense of thrift it took a week (if you were lucky) to get the machine up and working. The work had to be requested through proper channels, approved by a management committee and then performed by a bunch of overworked IT gnomes that also had to service several hundred workstations and a huge productions server-pool. We didn't even get to be Admin on our own Windows (by management mandate) laptops. Getting a port opened in the firewall on your own Windows workstation had to be approved by a security committee at management level. You can imagine how long that took. Needless to say most people solved these problems by setting up their own development environments. The result was a whole fleet of rogue machines. Every desk had 3-4 computers under it and workstations were regularly taken off the Windows domain by developers or Windows it self was simply quietly replaced with Linux. It was the only way to get things done and even then the pace of work was glacial.

    • Re: (Score:3, Insightful)

      by ckaminski (82854)
      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
      • by qoncept (599709)
        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.
      • by FranTaylor (164577) on Thursday December 31, 2009 @01:29PM (#30607176)

        You should treat your development machines as "hostile" and put them on their own network.

        You should do this regardless of security issues because developers can also do stuff like saturate your network.

        And what a great administrator, bashing people over the head because of your own limitations.

        I'm glad you don't administer my development systems.

      • by Darkness404 (1287218) on Thursday December 31, 2009 @01:40PM (#30607356)
        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 [xkcd.com] 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.
      • by bwcbwc (601780) on Thursday December 31, 2009 @02:17PM (#30607934)

        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: (Score:3, Interesting)

      by Kyril (1097)

      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.

    • by qoncept (599709)
      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: (Score:3, Interesting)

        by mcmonkey (96054)

        There's really two different issues. Reboot (or do anything to) a production server? Change ticket with approvals. Although in the best case developers should have no access to production. Updates should be packaged and passed off to a deployment team. (After QA and testing of course.) Reboots are handled by the infrastructure team managing the servers.

        But for my personal workstation and sandbox servers outside of the formal path of changes from test to prod? If I needed any sort of approvals to make

      • Re: (Score:3, Insightful)

        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.

        Nobody is talking about production servers. Not even testing servers. We're talking about developers' own workstations, and possibly development servers.

        If your developers can't be trusted in their own environment, then you need to find better developers.

    • 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: (Score:2, Insightful)

        by mcfedr (1081629)
        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...
    • 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.

    • by nine-times (778537) <nine.times@gmail.com> on Thursday December 31, 2009 @01:18PM (#30606998) Homepage

      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: (Score:3, Interesting)

        by Dr_Barnowl (709838)

        As a developer, the only things I pester IT support for are things that I literally cannot influence, like permissions on servers I don't administer, poking holes through the firewall, etc.

        Developers probably get into worse scrapes than the average user. Recently I had to have my Master Boot Record restored by IT support because policy forces us to use a full-disk encryption product that has a custom MBR. The average user would not have been booting Linux from an external drive and would not have run a badl

      • Re: (Score:3, Interesting)

        by Carewolf (581105)

        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.

        As a developer I totally disagree with your mindset, but I love the conclusion. Don't waste time on problems you don't have time

        • Re: (Score:3, Insightful)

          by nine-times (778537)

          Well of course I don't literally believe in "computer gods", but on the other hand I think superstition sometimes gets a bum rap. Is it bad luck to spill salt or break a mirror? If you live in a society where mirrors and salt are expensive, then it sure is. Even more so with breaking mirrors, since it leaves little shards of glass to cut your feet on. It's also a pretty idea to walk under ladders, given that you might knock it over (hurting the guy on the ladder) or the guy on the ladder might drop some

      • Re: (Score:3, Insightful)

        by curunir (98273) *

        I think you've somewhat correctly identified the what while incorrectly attributing it the the why. As a developer, I have less fear of changing things or breaking things not because I feel that things should work in the way I expect, but, instead, because I have confidence that I can fix things if/when they become broken. Sometimes it takes some Googling, but I can't think of a time where I wasn't able to fix a software issue. This mentality applies not only to maintaining a system, but also to doing our j

    • Re: (Score:2, Insightful)

      by gemada (974357)
      because IT does not equal programming or vice-versa
    • Re: (Score:3, Insightful)

      by HikingStick (878216)
      You hit on a major point. I don't know of any IT help desk or Tier II group that want's to be responsible for installing multiple packages, often multiple times a day. Where major headaches come into play is when, along with the "no admin rights" mantra, you get execs who start chanting "approved software packages only". This works fine for the typical desk drone, but it does not work for most developers, or even for some power users in other industries (e.g., CAD designers in manufacturing). When you s
  • by PIPBoy3000 (619296) on Thursday December 31, 2009 @12:49PM (#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.
  • by Knara (9377) on Thursday December 31, 2009 @12:49PM (#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.

  • this is what desktop virtualization is *for*. use vmware workstation or virtualbox and test away!
    • by Panaflex (13191)

      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!

    • 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: (Score:2, Insightful)

      by RingDev (879105)

      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

    • Hmmm. I think they're calling this client virtualization now. Desktop virtualization is where the desktop is in the data center.

      Strange terminology, I know.

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

    • 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.
  • 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 (Score:4, Interesting)

    by Alpha830RulZ (939527) on Thursday December 31, 2009 @12:54PM (#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...

  • 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, d

  • by pmontra (738736)
    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'
  • by wwwillem (253720) on Thursday December 31, 2009 @01:04PM (#30606768) Homepage

    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 (Score:3, Interesting)

    by Anonymous Coward on Thursday December 31, 2009 @01:06PM (#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.

  • It's Target. (Score:5, Interesting)

    by girlintraining (1395911) on Thursday December 31, 2009 @01:08PM (#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" (Score:5, Insightful)

    by Nerdfest (867930) on Thursday December 31, 2009 @01:09PM (#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.
  • by Anonymous Coward on Thursday December 31, 2009 @01:12PM (#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!!!

    • by bakuun (976228) on Thursday December 31, 2009 @09:41PM (#30611704)

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

    by pak9rabid (1011935) on Thursday December 31, 2009 @01:14PM (#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...
  • 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 da

  • by Reason58 (775044) on Thursday December 31, 2009 @01:18PM (#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'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.

  • Local admin rights? (Score:3, Interesting)

    by SmallFurryCreature (593017) on Thursday December 31, 2009 @01:20PM (#30607042) Journal

    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.

  • 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 c
  • 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.
  • 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.
  • by digitalloving (1540905) on Thursday December 31, 2009 @01:32PM (#30607214)
    One of the mid-sized corporations I worked for did not allow admin access to developers on production machines. The reasons for this has been outlined by some other posts already, but mainly because the server team was responsible for the servers. It was also part of a strategy to meet Sarbanes Oxley requirements for servers touching financial data.

    In order for it to work smoothly, an exact development copy of the production server is required. This is pretty resource intensive in both servers and admins. Second, the deployment of new applications needs to be communicated to the administrators. This took some time depending on the difficulty of the change. Finally, any issues that popped up in the production server that wasn't seen in the development server required "emergency admin access". It usually meant that a server admin and developer sitting at the same terminal working out an issue.

    This method, while not being efficient, forced a couple of best practices. First, because development had to be done a replica of the server, the code was already tested on a server that was identical(as possible) to the original server. Second, because the deployment had to be done by server admins, the developer had to document all the steps required to deploy their application. It let the admins know the changes being made, allowed auditors to see the change, and forced the developer to make an application that was reasonably easy to deploy.

    Overall, I think it lead to a pretty clean production environment with much fewer "surprises". However, any code you want to put into production takes twice as long and cost twice as much (approximately). To truly evaluate if it monetarily makes sense, the cost of a failure/fraud in a production environment needs to be calculated. I don't think it is always better one way or another. Although, as a developer it sure was a pain in the ass.
  • by PinchDuck (199974) on Thursday December 31, 2009 @01:46PM (#30607448)

    "You know the company policy, but now I will ask you directly: Do you have any software on your computer that I have not personally reviewed?"
    Yes
    "WHY?!?!"
    Because I write it. It's my job, and I don't have time to submit every program I write to you for approval before I install it on my machine to test it.
    Admin Draws deep breath...
    "AND...that makes sense. OK, you can have admin privileges on this machine".

    I know places that don't give their devs admin privileges. It makes their jobs much harder. Security has to make sense to keep a corporate network safe, not to inconvenience everyone or make their jobs harder.

  • by ap0 (587424) on Thursday December 31, 2009 @01:47PM (#30607476)
    My company's IT department is totally incompetent. Their solution to everything is whatever Microsoft sells, regardless if it's actually a better choice than another option out there. They don't even give any sort of open source solution a second look. My boss and I (the only two developers at our office) don't have domain logins and administer our own machines. We don't have access to any of the intranet apps, but I've never needed them. We do hardware development so we need admin rights. We administer our own development servers, as well. The NAS thing IT installed failed, and it wasn't backed up anywhere, so the entire office lost their shared and backed up data. Except us, since we knew that would probably happen. We don't trust them to back up our code.

    For the other employees at the office, whenever it's time to update software or install patches, one of the IT droogs calls an employee and tells them they'll be taking over their machine to update it (remotely, because there aren't any IT staff at our office -- they're all at another office). They do this in the middle of the friggin' day. And since they do the updates manually instead of automated updates, they'll take over someone's machine for sometimes hours, so they can't get any work done.

    So, yes, we have local admin rights. We are our own admins since we can't trust our IT department to do things right. We still have a single T1 to the office (actually two, but they don't know how to configure the router properly to get both of them working), and we're told to "schedule" our downloads for after hours so as not to use up bandwidth. I got blocked from the network awhile back for downloading some stuff to do my damn job. No warning. They just blocked the IP, so I'd change it, and they'd block it again. Finally they called me and told me that I need to wait til after business hours to get this 50MB file I need to get my work done.

1: No code table for op: ++post

Working...