Do Your Developers Have Local Admin Rights? 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?"
Yes (Score:4, Insightful)
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: (Score:2)
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)
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
That's what sudo is for (Score:4, Insightful)
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)
As a Unix admin with a development background, I thank you for being competent. I'm technically a security admin (for a huge financial company), so I spend about half of my time arguing with people about how they could just tell me what they need to run as root and I could provide them a sudo rule set - which would reduce the passwords they have to remember *and* keep the environment more secure + auditable (which, due to various regulations like PCI, is more important to the business than cowtowing to laz
Re: (Score:3, Insightful)
RH9 may be old, but not having root on it won't really be a significant detriment to a developer, unlike most windows setups...
Also, having old hardware encourages developers to write more efficient code... If you give developers the latest and greatest they will write code which is fast enough on their highend dev boxes, but uselessly slow when deployed on older hardware.
Re:Yes (Score:4, Insightful)
Having old hardware does not encourage developers to write more efficient code, it angers them and makes them disgruntled.
I'm all for test environments being constrained in terms of hardware if that's what a real-world production environment would look like, but to tell devs they need to use 17" CRT monitors running at 1024x768@72Hz attached to 1 GHz PIII systems with 512 MiB of RAM will not make them more productive (I've had worse systems thrown at me as "developer workstations" in the last two years, good luck running your IDE + debugger + test environment on that).
/Mikael
Re: (Score:3, Informative)
Re: (Score:3, Informative)
A few years ago, a 1ghz P3 with 512mb and a 17" CRT was considered high end, and people would be very happy to have one...
Hint: we just clocked over to 2010, not 2000.
Re: (Score:3, Informative)
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
Yes in DEV, No in TEST and PROD (Score:4, Insightful)
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)
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
Re: (Score:3, Informative)
You just need to be a member of the Debugger Users group, and VStudio works fine without being Admin.
It's not impossible to not be an administrator. I install all my services as an ordinary user and make sure things work OK.
It's a lot more comfortable to just be the administrator, sure, no question - but it's not impossible.
Yes (Score:2)
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: (Score:2)
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.
Re: (Score:3, Interesting)
If your devs had access to make changes to the production servers, then the failure was not with them -- the failure was on the system administrator.
As a developer, I try to have *no* access to any production system. If you're connected to the prod database server to, say, look something up for a customer (which shouldn't happen -- you should have tools for this -- but it does), it's far too easy to forget that you're connected to prod when you go back to dev-related tasks and accidentally wipe out a table
Yeah. (Score:5, Insightful)
Re:Yeah. (Score:4, Insightful)
Re: (Score:3, Insightful)
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)
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
You damn well should (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
How can a competent developer not understand operating system concepts?
Re: (Score:3, Insightful)
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,
Re:You damn well should (Score:4, Insightful)
That's not an example of a developer who doesn't understand OS concepts. That's an example of a moron who should be shown the door with extreme prejudice.
Re:You damn well should (Score:5, Insightful)
Wow. The scariest part of your story is people think this guy is a top performer.
Now, on the one hand, you can say he was very competent in operating his workstation. He knew how to install software. He knew how to configure said software the way he wanted. He knew how to change OS settings to make sure his software worked the way he wanted. He did all this without having to contact anyone else for support
Really? So 1) he owns the company? Or is the president or CEO? If not, why the fark should the world revolve around the way he wants his system to work?
2) Why is it a good thing he can get his system to work the way he wants, when he wants every hacker on the planet to get in to your company's systems through his laptop? And if that's not what he wants, then his software is not configured the way he wants.
Seriously, this guy is a menace. I can grab a chain saw and rip open someone's chest, that does not make me a competent heart surgeon. Yes, this guy made changes, but in no way should anyone say he is competent in operating his workstation.
Re:You damn well should (Score:4, Insightful)
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)
Re: (Score:3, Insightful)
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)
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
Re:You damn well should (Score:5, Insightful)
Re: (Score:3, Informative)
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
Re:You damn well should (Score:5, Informative)
...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:
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)
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
Re: (Score:2)
Development machines are not mission critical (Score:5, Interesting)
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.
Re:You damn well should (Score:4, Insightful)
Re:You damn well should (Score:5, Insightful)
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)
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: (Score:2)
Re: (Score:3, Interesting)
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.
Re: (Score:2)
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)
Re: (Score:2)
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 (Score:5, Interesting)
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)
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)
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)
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)
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)
Re: (Score:3, Insightful)
Generally, yes (Score:4, Funny)
Yes, because I'm not a masochist (Score:3, Insightful)
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.
virtualization (Score:2)
Re: (Score:2)
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 (Score:2)
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)
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
Re: (Score:3, Insightful)
I have 3 IDE's open because most of my work is front end stuff (AJAX/Silverlight), so I'll usually have VS2008 and Blend 3 open. Then if I need to be working on back end services, I'll have another VS2008 open for that. And invariably, someone at some point in time during the day will swing by with a question, debug request, or something else for another app, so I usually wind up with a 3rd copy of VS2008 or VB6 open.
For our SQL Server stuff I us the VS2008 server explorer, it handles most of the basic func
Re: (Score:2)
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.
Is this even an issue anymore? (Score:2)
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: (Score:2)
Ubiquitous in the mega crops (Score:2)
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)
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 developers admin rights (Score:2)
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
Yes (Score:2)
Virtualization is your Friend (Score:5, Interesting)
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)
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)
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)
What it REALLY comes down to (Score:5, Insightful)
Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem. The entire design of windows is to install **** under system32 or program files when it doesn't need to be there. I remember the old days when programs ran under one directory. Easy to maintain. You know where everything is. To uninstall is simply to delete. Don't get me started on the registry. REALLY? You're telling me it's "faster" than reading a text file config. Hardly. ARE YOU HEARING ME MICROSOFT? Why the **** do you even need admin rights? YOU DON"T!!!
Re:What it REALLY comes down to (Score:4, Insightful)
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)
Local,yes. (Score:2)
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
Information Security 101 (Score:3, Informative)
I work in infosec (Score:2)
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)
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.
Yes : Admin on personnal workstation (Score:2)
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
Developers Require Local Admin (Score:2)
Our users - around 2000 - have only normal user accounts.
Yes, local admin but... (Score:2)
Worked in Both Worlds... (Score:4, Interesting)
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.
Conversation with the company's head IT admin (Score:3, Insightful)
"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.
IT isn't allowed to touch my workstation (Score:3, Funny)
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.
Re: (Score:2)
Re: (Score:2)
Re:What? (Score:5, Informative)
Re:What? (Score:5, Insightful)
That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier, and never the twain shall meet.
Re:What? (Score:4, Insightful)
An Admin is well within his rights to maintain control over what is installed. Remember all the inadvertent leaks of documents because a user installed some file sharing program? That's an admin who didn't have, or wasn't allowed, adequate control over systems under his umbrella.
Developers DO need full admin rights on their dev boxes. You *really* don't want to be bothering the admin teams with "hey I need to restart IIS and/or reboot my machine" every 15 minutes if you're troubleshooting something.
the proper solution is separate networks where the developers simply can't cause significant damage by having admin rights. Unfortunately as has been said above, it's just easier to give developers admin rights on their systems without them being on separate networks from production systems.
Compromise (Score:5, Informative)
That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier, and never the twain shall meet.
About the best compromise I've ever seen is where admins say to the developers, "You can have local admin rights. However, don't keep anything important on your local disk (use network shares and source control), because we're not going to even attempt to support your unsupported software. If you bring your machine in with a problem, it's getting imaged, and that's that."
That usually makes the admins happy, because they don't have to increase their workload, and makes developers less likely to bork their machines, because no developer wants to lose a day reinstalling IDEs, etc.
Re: (Score:3, Informative)
Re:What? (Score:4, Insightful)
"worked best for me"? I'm sorry, but isn't your job to support the others and make their work easier, not the other way around? Obviously you should make your own work more efficient, but not in the expense of the others. So are you sure your solution has not harmed anyone? "It took some getting used to" sounds like harm to me.
Re:What? (Score:4, Insightful)
That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier^H^H^H^H^H^HPOSSIBLE, and never the twain shall meet.
There fixed it for you.
Re:Hell no. (Score:4, Insightful)
What has that got to do with LOCAL admin rights?
Conflict of interests (Score:3, Insightful)
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 u
Re:Conflict of interests (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
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-fing
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
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?