Slashdot Mirror
Do Your Developers Have Local Admin Rights?
plover writes "I work as a developer for a Very Large American Corporation. We are not an IT company, but have a large IT organization that does a lot of internal development. In my area, we do Windows development, which includes writing and maintaining code for various services and executables. A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers. My question is: do other developers in other large companies have local admin rights to their development environment? If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?"
We just have a development environment for them. Then once code is ready we copy the most recent backup image of the servers over, they install there, document how, and then our sys admins install. Done and done.
So basically, -1 troll/offtopic is really slashdots way of saying "I hate that you thought of something before me."
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.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
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.
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.
Whale
In previous places I have worked, the developers did not have local admin privileges on the machines on the network. We used virtual machines and test boxes that are disassociated from the network for testing and debugging, and the developers had full permissions for those machines.
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?!
We're local admins of the application servers, and a couple of us have domain admin rights. We generally haven't run into problems with this, as we have a strict policy of making fun of anyone who screws up badly. It involves Photoshop and is generally a memorable way to resolve the situation.
yes I do have admin rights, I couldn't do my job without it (we do have strict anti-virus that runs at 50% cpu all time time min). It takes forever to get IT or data-center to process requests so without local admin rights I would get almost nothing done each day. Actually we use windows machines to develop and don't deploy on windows machines. I tried to get non-windows machines to develop (makes sense to me) but to no avail.
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.
If you dont know how to work around this issue... You dont NEED to be an administrator to debug or install. That said, it makes things really easy if you have a way of getting administrative privlidges to your developers. But thats a policy decision isnt it.
this is what desktop virtualization is *for*. use vmware workstation or virtualbox and test away!
The way ive always had it set up even in troubleshooting environments is a corporate workstation , and a test-bed system. The corporate system was hooked up like ever other drone box out there, harsh lockdowns and limited permissions, set up with email and the slew of corporate software, then KVM switched to a test box, that was basically free reign - including changing hardware configs, the only regulation was asking the IT guy for a specific make of NIC, or a re-imaged HDD to swap out.
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?'
I work for a major insurance company. We work as a team with external personnel. There is always tension and in most cases, their personnel of comparable rank to ours earn more, appear to have more power over what we can or cannot do.
Mine yes. And since the dev environment resides physically on the same network of our production (separated by firewall), our server admins also have local admins to those machines. Software provisions are provided by the server admins, and we strictly monitor installed application on those servers by using software asset management tools. Testing is done not on the dev environment, but on another batch of servers specifically used for UATs, Developers has no local admin right on UAT environment.
HELL no.
One of my first gigs, the Rock Star Developers had admin rights. They'd pretty much do whatever they friggin wanted. And guess who got to blame when they screwed up? Yup, the sysadmin. Namely, me.
They'd go in and reboot servers - servers with 100 people logged in and working on stuff - because they thought their database was out of memory. Not tell anyone, nothing. One time they enabled an rsync script that pretty much overwrote a week's worth of work. And who got blamed? The sysadmin, for not making it impossible for that script to work anymore. Or something. It was crazy.
So basically, yes, it's an accountability thing. If I'm responsible for these machines, then I'm in charge. Period.
In the land of the blind, the one-eyed man is kinky.
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 :).
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
We trust our developers as much as we trust our admins. Actually, I trust our developers more than our admins, but the admins already have the highest privilege.
In soviet Russia, God creates you!
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 was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
I cannot imagine a developer that does not have Admin rights on his machine. Virtualization is a bit frustrating unless you have very powerful machines.
When I first started working where I work now, virtually every use had local admin rights and there was no web filtering. I brought these issues to a quick halt but I have no idea how my boss (at the time it would be a 1 man IT shop, just him) managed to hold it all together.
One of the problems I always run into is programs that require admin privileges to run. Not just install but to actually run properly. This is from the developers always having admin access and never actually testing under a user account. Things have gotten better over the years but there is still stuff out there that tries to pull this crap.
Sarbanes Oxley separation of roles requirements have been interpreted to mean that developers should not also be admins.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Under no circumstances should any developer in any organization today have corporate production administrative rights. Its simply not needed. As a developer and a security specialist, there's a lot of ways to get by this. First, you can create an isolated domain in a development environment, or even create a production domain that they can have admin rights to - other than the corporate production domain. Adding developers to the production administrative group is dangerous and all too often leads to problems. Just a few weeks ago at a friends company, a developer went into MS DNS and wanted to change a DNS entry, and ended up deleting several entries that brought down the Exchange server. At that same company a few months back, another developer wanted to add a static entry in DHCP but accidently deleted a scope that brought down a production site. There's just too much freedom for error.
LOL! Giving developers admin access to production machines is like giving grenades to babies, its only a matter of time.
Ultimately it comes down to a conflict of interest between developers who's interest is to changes things (new features, new version, etc) and admins who's interest is not to change things (SLA's, guaranteed uptime, don't touch a working system).
If this conflict is not properly balanced (dev's with fingers in production, admins controlling the dev environment), you will have problems and usually ends up being a very costly mistake.
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
I give them admin rights with the agreement that, if they mess something up on their computer, they are on my schedule to be fixed (i.e., when it is convenient for me, not for them). So far I haven't had any issues whatsoever. Then again, we are a pretty small department.
My personal thoughts on the matter are simple: If the IT staff feels they can trust someone with local admin rights then that person should have them if necessary. If that person messes something up, even if it is unintentional (malware, deletes the boot.ini file, etc.) then they lose the privilege.
"This food is problematic."
Yes at every company I worked at (150 to 50k employees). One large company had a developers and non-developers environment, both without admin rights but developers could ask permanent admin rights if they could demonstrate that it was required by their job. All developers asked their bosses, bosses did the paperwork and developers got admin rights. Not sure that everybody really needed it as most of us didn't write a single line of code but actually managed contractors that did the job using their company's pcs. For sure we enjoyed the ability to install whatever we wanted on our notebooks that often were our home computers too. By the way, guys with admin rights had to fix of anything going wrong with their pc because requests for assistance would be billed to the budget of the company unit they belonged to.
Me I just overwrote the Windows disk with a fresh Linux install of my choosing. I got to pick the root password.
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.
Browsers shouldn't have a back button!! It's all about going forward...
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.
Developers have their machines; I have the servers. How could it be any other way?
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...
#fuckbeta #iamslashdot #dicemustdie
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.
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.
On their personal laptops, yes they do. On servers or laptops used as test machines, no. Think about the security concepts of least needed access and separation of duties. On their personal laptops, they may have a need for being able to quickly and freely do certain things. But once you get to anything approaching production, they need to be locked down.
Yes
Give them admin access to machines on the dev network, but not on the production side. Development shouldn't happen on the production network. Many developers don't realize that when on the production network they can take down the entire network by downloading some crazy app or better yet screwing up code that floods the network. Setup a lab network behind a firewall, then allow ssh traffic and maybe a few other ports to allow controlled remote access. If the developers screw something up, it just takes down their lab network.
The international company I'm at, was talking about taking it further than this, and removing admin rights from the IT staff... Yes, I believe managment degrees need to be a Masters or PHD ABOVE what they know, not a degree to be in charge of what they don't know. Right now it's like "goto college for 2 years and qualify to be the General of our armies" Another pitfall of a truly ignorant society.
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!!!
Are you insane?
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 databases. Where I work now, we have free reign over the dev environment. We can do what ever we want and not tell a soul. If anyone is running production apps that hit the dev environment, it is a critical failure on that developer's part, not on the part of the person rebooting the dev box. We can change database schemes, install new apps, run windows update, all the usual stuff. From there we have a staging environment. The staging environment is slightly more locked down, we can still do almost everything we did in the dev environment, but all changes and reboots have to be communicated so that all other departments that may be deploying and testing are aware of the changes. After that is the production boxes. We do not have rights to get into these machines. We write up instructions and submit tickets to the support staff for deployments to these servers. All those deployments run on Thursday nights after a week long "train" process that involves IT managerial, tester, and power user sign off.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
I work for a state agency, and surprisingly *everyone* here has local admin. This is a stark contrast from when I was enlisted, as not even Help Desk or Server Room had admin rights anymore as they had consolidated everything upchannel.
For windows, by default no. You can programaticly acquire a local admin account, but doing so is also an opt out for a good chunk of IT support.
For linux, you almost certainly have full sudo rights for the box under your desk (and could get root trivially since you have physical control of the box).
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Why not use vmware or similar?
Recently I've been tasked with network administration (I've been an admin for over a decade but this is not what I was hired to do).
The first thing I did was remove all local and domain administrative privileges from IT and senior Management.
The only person it effected was the IT Director, and once I made the appropriate local file permission changes it was fine.
A few weeks later he found he was missing access to one directory he needed so I logged onto the admin share c$ and gave him access. He was shocked I had remote access to view his files. This was a great boost as to why I have revoked administrator privileges from numerous people (I think I saw him breath a sigh of relief).
Anyway, the administrator access removal has not effected the IT Development team one bit. Once they have all the apps they need installed on their local workstation, and server level access configured for directory/file permissions, they're good to go about their development without a care.
Dan
Who here, at some point in developing with Visual Studio, NOT seen it pop up that stupid message saying you have to run the IDE with administrator privileges for something or another?
Here's a quick link with just a few of the examples:
msdn.microsoft.com
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
Wherever You Go, There You Are
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.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
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.
I work for a company of ~6500 people, and every last one of them is a local administrator. I work helpdesk, please pray for me/send me booze.
This is my 4th workplace and at all, from a 4 persons start-up to a international investment/corporate bank with a 1500 dev department, all dev had Admin rights to his own station.
In theory, you could be writing software as a simple/advanced user and the IT dept can grant you the exact rights needed to do so. BUT there is a huge amount of complex access rights involved when working on Windows using VisualStudio with no exact list of what are exactly the rights needed. MS tried to simplify the process by creating dedicated groups (like VS Developers group or Debugger Users group). At the end, most of the time, the IT dept simply grant local admin rights to every dev so they are not disturbed every 5 seconds because a very complex to trace access right is missing.
Sig (appended to the end of comments you post, 120 chars)
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.
The Kai's Semi-Updated Website Thingy
Any shop that knows what they are doing would do it this way: - dev environment for devs to monkey around with; seperate network from prod - UAT (and possibly INT) environment for dry-runs of deployments also on a separate network, also used to document said deployments - PROD, accessible only by a handful of staff who follow documentation created above
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
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.
Why bother
Programs that do are just sloppy/lazy coding. Unfortunately that describes most of the code out there.
I regret that I only have one mod point to give per post.
Developers administering PROD boxes?
Apparently you do NOT go through any SOX or HIPPA audits
Wherever You Go, There You Are
The answer is that it depends. Admin on their own workstation, absolutely. Admin rights on a server, not unless they have a really valid reason to violate security policy.
The code needs to run in user mode, there are few reasons for the developers to run higher than that.
We have all seen examples of where running in user mode breaks code. There are very few valid reasons for that.
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.
Windows Developers need Local Admin access to the machine they write code on, debug, and run their local unit tests.
When "code goes wrong" not having admin privileges means that some debugging tools are right out. File and Process monitors, network sniffers, and some of the Visual Studio debugging features just don't work without some elevation. This situation gets worse under Vista and Windows 7 (which is actually a good thing for Windows).
I've had this fight at a few jobs and this is a deal-breaker. Give me Local Admin rights, look the other way while I subvert your system, or accept my resignation.
Test machines, servers, etc.. no, never. It's not necessary and (in the long run) subverts sane release procedures.
Get off my lawn.
Even some large military networks provision developers with secondary accounts that have local admin rights. The machines on which those accounts are valid get walled off into a "community of interest" that is isolated from the production domain. You can't effectively debug on Windows without those rights. However, it's very important to know where those rights are required and not, and developers should do as much as possible without invoking them. The assumption of excessive privileges has always been a big hassle with Windows. Microsoft started trying to kill that off with XPSP2 and Vista, and they are still trying. Speaking of which, they used to have a white paper (NT4 based) about security in a development environment, does anyone still have a copy?
We give developers local admin rights to dev and test, for QA and production environments all changes go through change control. Like others have said I have said I don't trust developers either. Most are clueless, in over 15 years I've only met one developer that actually understands systems administration.
My group does use quite a few non-standard issued software that, for the most part, the rest of the company don't use. Incidentally we also support field techs that are in the middle of nowhere, far, far away from us on those software as well. Based on the control systems our company has acquired during acquisition or what has already in placed, we have numerous systems varied by vendors and even seperate generations of systems by the same vendors. It is actually a great deal of pain to just "upgrade" the system to one platform since our upgrades does involved physical change out and that means lost production time that can be quite costly in a 24/7 environment. We manage and support those self packages (to ourselves or other techs that may have to use it from time to time to support us).
There had been talk in the past to remove the local admin rights from our laptop in the past (for standard IT policy for all desktops and laptops). Being the fact that we do go off-line during our normal work assignment it is near impossible to do any work, especially having to install/support others and not having local admin right to add/remote software packages. Some of our software packages, in fact, requires a local admin account in order to function.
The day we lose local Admin privledge is the day we pretty much come to a complete stop. We had this discussion twice in the last few years. It simply comes down to that. We will be responsible for our machines (all of us knows at least how to keep our machine working, hardware and software) and Security leaves us along with the local admin rights.
Developers are not admins. Admins are not developers.
Any time you start letting one do the job of the other it will end in disaster. *Guaranteed*. Developers simply don't understand all that comes with years of doing admin work and the reasons why they have stupid policies and "red tape", and Admins make lousy coders because they don't understand all that comes with years of writing software that actually works and why the quickest easiest script is usually the worst.
A competent developer could mean "competent to win the Netflix challenge" but not be bothered to learn OS-specific peccadilloes. (I agree that they certainly would need to understand totally general OS concepts stuff like what a file is.)
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.
They have admin rights on their desktops and they have a virtual machine on a vmware server that they can do whatever with.
There are a couple development servers that they just have shell access to, or are power users or backup operators to let them start and stop services.
At one point the director of development asked me to give a developer root access to a server. The dev didn't understand how the mounts were supposed to be setup so he went through and "fixed" the configuration files without commenting anything out or leaving any hints. I had backups of the conf files of course but he messed it up on a friday afternoon.
Most of you are right, dev's don't need admin rights to run their code.. but wtf, they should test this on test accounts anyway.. and it's a hell of a lot easier to install applets and whatnot to help you code when you have admin access..
~Mekkah
A few developers (i.e. the 5-person team I'm on) in my organization (government) have superuser privileges on their own machines (Macs) and a few of us can sudo on our local Xserve (which is totally internal and run by us/our local Mac sysadmin, not the "corporate" IT folks) to do things like read log files, update MacPorts, etc. We don't have superuser privileges on any of the production servers (though we should have a bit more flexibility than we have on said servers, which could be setup through sudo without allowing us the ability to change software on the machine, etc.).
-Matthew Riley "TofuMatt" MacPherson
I have a website
No, why on earth would they need local admin rights? I can't think of single legitimate reason to grant such rights. Testing should be done in the lab and nobody should be installing software on their own.
We're a small company, developing on Windows using Visual Studio. Since Windows XP, all our developers work in a normal user account; as nearly as possible they use the same environment the most restricted of our users might, so that dumb security-related mistakes get caught fast.
Having said that, they also know the local admin account details for their machine, and are entrusted with installing/uninstalling stuff as necessary.
That differentiation - between the access we allow and what we encourage as day-to-day practice - is an important one. On other OSes you're more likely to be making this differentiation already. If you're using Windows and don't, please consider it. This is a useful resource: http://blogs.msdn.com/aaron_margosis/
I'd be more worried about accidentally building in dependencies on "hundreds of small programs" that won't be there in the final environment.
This is why you also have a QA department which is in charge of installing the dev's work in a "final environment" and checking it.
(Ironically, we don't have a QA department where I work. /facepalm)
"We trust our developers as much as we trust our admins. Actually, I trust our developers more than our admins, but the admins already have the highest privilege." - by blai (1380673) on Thursday December 31, @11:54AM (#30606580)
Which makes total sense, because, without developers?
These "admins" (network admins/techs) are MOSTLY imo @ least (and they always HATE when I say this, but it is the truth as far as I am concerned, having been both a tech/network admin (for my first years in academia & the first few out of academia to earn a living))?
Well - a fact's a fact:
MOST are just "users with a better password" really (they really don't build a lot of serious code, or larger projects is why I state this (& IF they do anything like coding, it's mostly either SQL, or batchfile/scripts work @ best/most).
Imo @ least: Coding, & especially @ the "enterprise class" level of development (larger systems basically & with more than just SQL only OR batchfile/scripts work) is the ULTIMATE EVOLUTION of the "computer person" really...
It really IS much more difficult building a solution, than using what's already built.
When working as a coder, basically, YOU are the one "inventing" a solution when you code, whereas network techs/admins really MOSTLY only USE what has been invented for they, or others, to use.
I have called networkers/techs this before in debates over this, & again - they didn't like it much, but, that's only telling me it struck a chord with them (as truth usually does):
"Network techs/admins? They're just users with a better password"
And, yes, most don't LIKE that, but... compared to what coders learn AND know (especially what is gained on the job in the actual trenches doing the work)?
Well... look @ the degree courses track that CIS folks take, vs. those in CSC. That tells you WORLDS, right there... &, most admins/techs I have encountered? They usually don't even have the CIS degree - They usually have an A+ or MCSE type certificate... not actually degrees.
Now, for those of you that *THINK* there isn't a difference between getting a full-blown degree in CIS vs. just getting a cert? You are SADLY mistake IF you think that is true that A+ or MCSE is as solid & as good a training program as a CIS degree is.
(& most coders, with a few years to decades under their belts that is, are usually QUITE proficient as network administrators (have to be, in order to DO the job, period))...
Sure, some folks here may not like what I've said here (the majority, & certainly those who are just admins/techs) but...
That's about it, when a network tech or administrator is compared to a developer in terms of skills!
AND, again - I can say this, because I've been both, professionally (tech/administrator/programmer/programmer-analyst/software engineer has been my path since 1994 professionally).
I say that, because of a SIMPLE fact, too:
MOST techs/admins really don't function period without the tools that programmers/developers make for them to USE (without which? MOST admins are helpless as babes in the woods).
Admins & techs? In my experience (16 yrs++ now in the working professional world in this art & science/field, much of which for the 1st 1-2 years was tech/admin, & then later moving up to development jobs primarily & only)??
Most of them don't code, & imo, they limit themselves in that capacity &, lord only knows why, but, many do so.
E.G.-> I had a colleague on the job once whom I told "you'd make a good dev" back in 2006-2007, but he replied "I'm not crazy enough to become a coder, nor, would I want to. I am happy where I am"...
OK - which is fine, I suppose, but... it's a self-limiting viewpoint I felt.
I mean, why be a techie or admin only, when you can be more + earn more because of it, & strengthen what you may have to offer & use one day, on the job, especially if there are no
If I had a nickle for every time i had to go into a system and fix it because some developer screwed up the server I'd be able to quit and buy an island. Developers need local admin rights to development systems only. Not testing, not staging and certainly not production. But I get both on and off-shore whining every single day. Sometime management listens and I get to tell them "See!? I told you so!" when it blows up later. I thank the Lord for VM daily as it lets me repair the damage developers do to our systems in minutes rather than hours.
I do some development work in a healthcare environment - I have root on a dev machine and user level access on a testing machine.
I think you actually need both - the ability to change things for testing and development, and the ability to test on a generic user machine.
All employees setup, administer, and maintain their own machines. Indeed when you get your machine it's in the box (often refurb) and it is up to you to get it setup, download the internal authentication software and connect to the services you need. They really do eat their own dog food and it must save them an amazing amount on IT costs.
it's interesting. in my area (gov't programming), we have Windows boxes for our documentation and issues software, but we develop everything on Linux (aside from our website, which is .NET based).
if you really, really need it, they will give you Admin rights on your Windows box, but I don't know of anyone who has ever needed it. I spend 1% of my time on my Windows box. i can see the issues from Linux, and have exported the documents i need so that I can view them in Linux. i use my Windows box once a week to fill out a particular time card (i have 3 of them).
we all have sudo rights on our Linux box, and Admin rights on Windows are not given out at all. our home directories in Linux are nfs mounted, as well as a few other locations. if it is software that is needed by everyone, it is pushed to a nfs mounted partition, that way everyone can use it (a lot of our libraries work this way).
our software does a complete reinstall of the OS (RH), has to update cron and do a lot of other things. sudo is absolutely necessary to test stuff out.
IMO, admin rights can be given to developers. if i need a package installed, and our IT guy(s) are out, then i don't need to wait 2 days to get moving on something.
I'm not even sure why this has to be asked. If a developer doesn't have local admin rights in at least some environment where testing can be done, then the developer simply can't do his or her job. This just seems obvious to me.
Where I work, employees in IT related groups have local admin rights to their workstation. Additionally, we have multiple test environments. We have a development test environment where developers, as well as QA, can do their testing. Then we have a staging environment, which mimics production, where only administrators have admin rights, just like in production, so that the software being developed can be verified to work in such an environment before being moved to production.
I do work in a very large corporation.
Developers have near admin privileges. Everything is locked down via GPO, and developers are in our own OU.
We are admins on Development and Production servers so that can we handle application deployment, maintenance etc.
There are still some functions that we don't have access to, things like the virus scan, HIPS, Desktop validator, Smart card interface etc.
We can install/uninstall applications etc, but there is a finite list of software we can use, and if we get caught with unapproved software on a computer on the network, we will have a lot of explaining to do... to people with sidearms.
It is absolutely necessary for most developers to have admin rights to download and install software. The problem is that there is also a potential for downloading/installing Trojans. The appropriate solution is to have seperate Development and Production networks.
That being said... I work for a corporation that does NOT have seperate Dev/Prod networks. Our solution has been to apply for temporary admin access the first time we install some new software (for example, VS2010 beta) and then have the developer create a local admin account to use as a backdoor once the temporary admin access has expired. Not the best solution... but better than waiting for 2 weeks every time you want to install a patch.
I've worked in a variety of situations ranging from developers having root access to all workstations and production servers to having no admin rights on the workstation at all. There's a definite connection between developer's admin privileges and overall corporate culture. The less permissive the workstation environment is for the developer, the less creativity and innovation flows from the organization. I've especially seen this in banks where you're not allowed to install any software without a security officer's blessing. Contrast this with my current company, where each developer is fully responsible for maintaining their machine.
By depending on each other to understand the OS and learn the best tips and tricks for choosing which tools to use, every developer becomes capable of troubleshooting issues on the production machines. As a result, we takes just one operations / sysadmin person to manage the systems for a 20 person company. Of course, granting that level of permission requires a high level of trust that is often earned over time.
Windows has a variety of rights and privileges (see: http://technet.microsoft.com/en-us/library/bb457125.aspx ) Developers should have debug privileges but should not be full administrators. It always surprises me that administrators do not use the fine grained control of privileges that is available to them when creating groups. When developers are given full administrator rights the users often find that the program will not run propperly under a normal (non-admin) user account. The test group must use accounts that have exactly the same rights & privileges as the eventual users.
...as a consultant then yes. In fact, often the whole IT department. The desktop guys will wipe and image your installation if you trash it and there's usually installation packages for the main development tools, but otherwise you get no support. It's assumed that if you work in IT you either know what you're doing, or at least you have the good sense to not break what you don't know.
Why? Simply the rate of tools/users, which makes it very inefficient to do it any other way. For example, I regularly locally use an import/export tool which is only useful to 2-3 people in the whole company and there's a new version with every point release of the server. File a submission form and have an installation package created? Wait for one of the blessed system administrators to install it, who'll do nothing but run around and be internal overhead? Forget it, you trust me to manage a server used by hundreds of people but not my lone box? It's like handing me scalpels with one hand and safety scissors with the other. One thing I've come to accept though is web filters, it's amazing what people will do at work. I don't pretend to be a saint or anything close, but the worst I tend to do at work is read slashdot - the rest happens on my time, my internet connection and my own PC.
Live today, because you never know what tomorrow brings
"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.
I'm a client systems integration guy, so IMO it would be a good thing to not give developers admin rights by default. In reality though, they do have them. In a bureaucratic IT world, it just makes them more productive. We've been trying to eliminate admin-by-default for ages, but the supporting stuff isn't in place yet.
Modern versions of Windows do work a lot better with limited rights, and Microsoft has done a decent job in trying to make the limited-user experience a little more transparent. In a perfect world (which I don't work in,) all software distribution, upgrades and removal would be fully automated through SMS or something similar. Every relevant system setting someone would want to change would be open to non-admins. However, if you work in previous versions of WIndows (XP, 2003, etc,) then some key things a developer might want to do (i.e. start and stop services, install drivers and make registry changes,) require elevated privileges or relaxing system security. Plus, even with compatibility hacks, some older software just won't run reliably without privileges.
I think developer accounts should be limited rights by default, but they should be allowed access to a privileged account for installations and system changes. The caveat is that developers need to realize they're writing software that won't be used by admins, and have to test anything they write in a limited rights environment. I can't tell you how many (large) vendors I've called while trying to integrate client software into our limited-rights environment. Some are totally shocked that we even have users running without full rights. I've found this to be the case most often with "niche" vendors who aren't making a consumer product, and training companies. The latter seem to just assume that everyone has full control over their web browser settings, can install whatever plugins they want, etc.
One of the ways we're working around this is using virtual machines for lab work. The developers can mess these up all they want, and restore them if something happens. The catch is that they don't have direct Internet access, which is the main reason why admin rights are so dangerous.
The problem with running admin-by-default is the amount of damage someone can do, even unintentionally, by using an account that has rights to make any changes. How many people do you know that actually read the UAC or download warning prompts while they're browsing the web?
I'm a hardware developer at a Very Large Corporation, and IT would prefer us not to have local admin. However, it's nearly impossible to work like that, so they have set up an automated tool (which basically goes and asks our manager for approval) for granting local admin exceptions on a machine by machine basis. In theory it takes away our local admin powers every month, but in practice, so many people need to have local admin I don't think it ever actually removes local admin.
You just can't do serious work without being able to install software, install drivers, use remote desktop(!!!!), etc. Not to mention many CAD apps simply don't work if you're not local admin. They tried forcing us off those applications, but we just started using raw OS images and installing a VM with the "corporate OS image". They threatened to fire us, but at the end of the day they need us more than we need them, so we ended up in this hole.
Honestly, installing your corporate locked down image in a VM is the best way to go anyway. Let IT do whatever they want to that image, they can reboot you, push updates, etc. without disrupting your work. Meanwhile you can set up the OS for your productivity without disrupting them. Yes, it's a flagrant disregard for what IT is tasked with doing, but chances are if you're in a Very Large Corporation, what they're tasked with doing is ridiculous, the number of people assigned to do it is pathetic, and the geographic and linguistic boundaries of that ensure that their mission is defunct. This is probably not ideal behavior, but I consider myself an engineer first and an employee of Very Large Corporation second. Better my job gets done correctly than I invest time in fixing stupid. You can't fix stupid.
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.
On their local workstations, yes. On their development boxes, yes. The Release Engineer should have control over the QA environment. It should mimic production as much as possible, so developers shouldn't have admin rights. On production, absolutely effing not. The world of virtualization has provided new tools and methods to use for development purposes. These should be used to their fullest extent.
Nothing to see here but us trolls...move along...
if not some of the development tools won't work and nor can they install service packs and bug fixes for their system to test them out.
If I as a developer have to wait for an admin to install the bug fixes and service packs for me, I'll get less work done and won't be able to function. Also VB 6.0 controls will refuse to work unless I am admin meaning I can no longer use some controls to program with.
I am not asking for admin rights on the server, just my own PC I am assigned to develop on. Jobs I had where they took away admin rights for my local PC were very hard as they tied one of my hands behind my back and made it hard to work.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I will agree with you that any machine that is used to run production applications, particularly those attached to the internet, need to follow a strict lock-down. The very first concern should be permissions, permissions, permissions with nobody loggin in as root (admin whatever), using sudo to promote to 'admin' and thorough logging of any escalation of privlidges.
From a developer standpoint, if somebody is calling me at midnite and asking me to log into a prod box and fix something.... Then there is a hell of a lot more wrong in the organization than a crashed application.
That said, attempting to enforce that level of security on a pc used by a developer is pretty much an exercise in futility. Either your developer will just 'give up' and let thmself fall behing in tool updates, or they will get 'wiley' and saturate your support staff with calls to perform 'desktop maintenance' until your organization gives in a allows local admin.
Wherever You Go, There You Are
Locally and to the development and staging environments yes, they typically have administrator/root/sudo privileges almost any where I've worked. It's almost impossible for them to do their job well if they don't.
It's trivial to get admin priveleges. You are a developer after all. Just develop/package your own backdoor trojan/etc that gets installed with root priveleges. Then get those fancy administrators to install it for you with their admin rights. If they ask what it is, tell them its some libraries for a development project. The number of times you'll be asked will be next to nil though. Voila, you can do what you want after that. Not that I've done it, but on the unix side, you could ask for a sudo exception for a program that's in a directory that's writable to you. Boom you have root any time you need it. You're a developer! Use your skills! Yeah yeah, there are some HIDS systems that will catch this sort of thing, but there are ways around that too. After all your root/admin at some point. If you don't trust your developers with root, then you shouldn't trust their code!
You're a developer, you have a compiler. IT doesn't realise it, but developers aren't bound by any requirement for "admin rights". If developers want a piece of software, they can just compile it and run it. It's pretty standard security theatre.
I had a friend working at a company where he didn't have admin rights, and he wanted to run a Wiki. The IT team didn't give him approval, so he downloaded Apache, Python, Perl and a Wiki. Compiled them all and had a Wiki running on his locked down machine within 3 hours.
Locked down desktops are easily subverted when someone is given a programming language.
Working at a large financial org as a developer - everyone has to run a windows desktop, even if their deployed code will reside on unix servers. So, we all get admin access off the bat, which is usually required to install the tools (IDEs, testing tools, beta versions of stuff, etc.).
This becomes evil, as it opens you to drive-by OS infections via the IE and Outlook. Not fun.
Support is basically if we hose the machine, support will reimage it. If this happens too frequently, admin access is removed, and the developer labeled a 'tard (unoffically of course).
I would personally prefer two accounts -- one as normal joe user, one as admin, so I can at least dip in and out of admin rights, minimise the risks, but big companies seem to do things all-or-nothing.
Isn't this what virtual machines were created for. Lock down the main PC and let them play in the sandbox? But I am not a developer so I don't know if this would suck or not. At my office everyone has admin rights and it makes life hell.
Not just no but, No Way In Hell!!! Ever!!!
"Be wary of the man who urges an action in which he himself incurs no risk."
~Joaquin Setanti
Well, in my environment, many dev's have been outright fired for making production changes without following the change management process. Typically, they do it once, get a written warning and if they do it again, they are fired on the spot! The company has a zero tolerance policy regarding change management. Too many times, production systems went down and cost the company millions because someone made an unauthorized change.
Everyone is in fear of pushing to production. Now if you have followed the change management process it dictates you must have a rollback plan if anything goes wrong. If it's a high risk change then it needs executive approval.
Of course, now you just need some little thing that is very low risk and it's a major pain in the arse to get anything done quickly!
I have now been a project manager for 2 Global 200 companies and both gave developers limited admin rights to their machines. They have full rights to install anything on their machine and configure services but don't have the ability to perform user permission changes and such.
It really depends on what kind of development they're doing. Speaking as an Enterprise Windows developer who has had to install clean OS's regularly (hurray for virtualization) and test products our with ActiveDirectory integration, I can say that sometimes development groups need their own domain controller to play with. In that case, give them their own domain and consider putting it on a network segment separate from the rest of the organization. Set up the routes and a domain trust relationship that allows them to get corporate email and access shared folders and printers, and you're all set.
Even if developers don't need their own sandbox to play in and don't know how to administer a domain controller, it may be a good idea to set it up that way for security reasons. Developers tend to be lax about in-house security, and it helps keep systems on the rest of the network from being able to access development files they have no business accessing. If they do any network testing, it also may keep them from killing your firewalls, servers, Internet bandwidth, etc. (that's one reason my group got moved to our own network segment with its own Internet connection ;-) If they do any security testing, they also may install malware on purpose from time to time (that's another reason my group got moved to our own network segment ;-).
I've worked at places where individual users (developers, engineers, and other tech savvy folks) have admin rights.
In every case, it's a balance. The ease of getting things done quickly vs. manageability and security of the computer involved.
If you lock a computer down so the installed apps can be used but nothing else can be installed, it tends to be relatively stable, and you don't get rogue programs installed that cause problems and generate extra work for installers and work disruption for users. The other end of the spectrum means anyone can install what they want. You give rights to everyone and end up with constant rebuilds and virus problems, etc. These can be just minor annoyances or in the worst case can disrupt business or cause legal issues (like loss of private or protected data) that will shut the company down. At the very least they create lots of extra work for someone in the company.
So, many managers (tech savvy and not) are deciding that they need to lock down control of work computers. Basically, they remove the ability to do anything but run work related applications (centrally installed to ensure licensing works and to make sure everyone has the same version) to simplify support and lower costs (which are a big headache for any IT manager).
This makes things more complicated for individuals with legitimate business reasons to install software (like dev add-ons or new versions of libraries, etc). In the case of a locked down system, the central authority in the business for support needs to provide a way to respond to requests to install needed software quickly. This can be either an automated system with menus, or an on-call support staff that handles things. With remote access to desktops they can generally get things installed quickly enough that work isn't significantly delayed. If and only if management recognizes that this support is necessary (people hear what they want to hear, and too often management thinks the clamor against locking down workstations is simply bruised egos (see below)).
This problem comes in when a company decides to solve its rogue software problems by restricting desktop access but doesn't provide any way to request "special" software. Unless your company is very unusual, certain users will need software that's not generally installed everywhere, and not everyone will fit the "standard business software" mold. This is a rough parallel to IT departments restricting access and forcing change control for "production" tier systems without changing their development processes to remove the need for production access. You're left with a choice to either break the rules or not get work done, and god help you if you try to explain things to whichever manager is getting a pat on the back for "securing the system".
Of course, the reason most people ask questions like the submitter is probably due to ego. The emotion behind the question runs roughly "I'm a smart (guy, girl).. I've been progamming and running my own system since before this OS was released! I don't need a low paid staffer to handle this for me, and you're just slowing me down! I feel insulted by you not giving me privileges and trusting me to keep things working!"
Having control is a hard habit to break. Taking it away from people who've "always" had it is like introducing change control to a company that's always been a free for all... people see the change as extra procedure being introduced that is unnecessary and slows down "real work".
The best way I've found to deal with people who want admin rights because their ego demands control is to ask them if they're also willing to accept responsibility for their workstation being productive. The desktop support folks or central desktop team accept this as part of their job.. in cases of heavily regulated industries, there may be legal requirements for someone to be responsible for the integrity of such systems. So once you get the person complaining about a lack of access rights
I just left a company after 3 years. What amazed me(as a developer) was that not only did we have local admin rights, we had global rights. This was ok for me as I have an element of sysadmin understanding, but my ex boss who used to be an administrator but now runs the BI systems did quite 'get' admin rights and the systems we ran.
Every day he'd randomly reboot servers, install different software in different places and generally make administration and licencing a nightmare. Also as a developer he didn't really have a clue as to how to organize things properly so things like SQL Server could only run one database on one machine, if he'd actually asked around (ie the sys admins) things would have been far easier, and I wouldn't have quit.
So in a nutshell testing servers with admin rights, fair enough, online servers with admin rights, don't let developers near them.
At my last position I was at a local market level. The local market had its own IT team with security policies given to them by a division team. Division got its policies from corporate. Sometimes things were altered to suit the divison or local market, too. When working there, I had full admin rights to production servers, but not to the PC from which I worked. This was stressful as I was forced to develop in the production environment. It was also ironic that I had admin rights to these servers but not my PC. It was because IT did not have the training or time to admin the servers (SQL and SharePoint). I did my best to have the local IT team install software after software to enable development from my PC as best as possible. After about 9 months on the job, I obtained a development server that I could work from via remote desktop. By then, I had already developed processes to develop from the production server. Also, the development box was SLOW and annoying to use (an old Pentium III box...). This all seems a bit backwards and it took some adjustment, but it worked. I became a hero for being able to manage these servers as well as develop new tools for the local market. I got along very well with the IT department and they were very competent and helpful which made working with them easier. I would have appreciated local admin rights, but the local IT manager was not able to bend the rules for anyone without getting in trouble if audited by division. I am working at the same company at the corporate level after moving up from the local market level. At corporate I have full admin rights to both a desktop and laptop for development. I do not have admin (root) access to development and production servers though. We have a sysadmin team dedicated to protecting our servers from ourselves. Change request procedures ensure the environments are modified properly. For PC support, We have a local IT team that reports to the division office as I sit a thousand of miles from actual HQ. There have been times where admin rights (root) to servers would be nice, but we have 10+ developers relying on that server to be available for work/testing/etc. So, I can understand why the servers must be managed by an SA team. Change requests are simple and usually accomplished in a fair amount of time. For times I absolutely need root access to try out new things, I just build Virtual Machines on my desktop and try before I place a CR for the dev servers. Production CR's are much more strict and those servers never have compiling tools to restrict local users from building binaries that could break things.
... one moron who used the privilege to turn off her virus scanning.
A woman! How old is she, and can I marry her?
Jokes aside, is there a reason why she turn off her virus scanning? For example, rushing a project, or the hard disk getting slower, or the antivirus somehow screwing up her work, or something.
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.
A developer needs elevated rights on a virtual machine where they have a saved snapshot they can revert back to in case they bork things.
Yes, we have local admin rights, with the caveat that we don't call the help desk for most things. We're expected to fix our machines ourselves, and be responsible if we spread virii or other malware.
I work for a very large DoD contractor - we are given local admin rights as software developers - note these are only for the local machine.
I was a cross platform development team lead. We were constantly forced to upgrade systems to faster and faster CPU, Disk subsystems, and more RAM yearly to improve developer productivity. Add new compiler releases and updates to 3rd party libraries that needed to be deployed across 50 developers and you could easily lose a week/dev of real productivity.
Then we switched to development servers - where the developers used RDP or X/Windows or ssh to remote into the boxes. They didn't get admin and all developers for the team used identical (not just the same) environments. Since some of our contract developers were overseas, this simplified contracts and security requirements too - the code never left our servers. We weren't constantly having to purchase more compiler licenses and other tools either. This is harder with Microsoft tools.
With server-based development and virtualization, we can cold-backup an entire development environment for a release and keep it around, just not running, for as long as a client is willing to pay for updates or support. If it doesn't happen for 2 years, we didn't waste anything but a few hundred GB of offline storage.
Server disks connected to SANs with caching are FAST. Faster than any local disks. Compiles are 10x faster.
IMHO, most current developers that aren't C/C++ seem to be clueless about performance of computers. Developers can lose days tweaking their desktops "just so" rather than getting down to work and concentrating on the important stuff. You know, code comments.
Junior developers: no, unless they had a pressing need for it.
Senior developers: yes.
There is a responsibility and trust issue here. If you have root/admin access, the general idea around here has always been "you break it, you fix it".
...laura
I've been the sys admin. I've been the developer. I've been both at once.
Security guys tend to forget that work needs to get done. Developers tend to forget that the way they want to do their job is sometimes not allowed (we security guys often don't make the rules, we just get busted for not following them) or is illegal (I don't care how much you need $COMMERCIAL_PACKAGE, pay for it or keep it off my systems). This is not entirely by accident. It's just separation of duties. If you have two important jobs to get done, and those jobs conflict, give them to separate people. If you give the whole thing to developers, they'll develop software and not worry so much about the security bit.
The general problem is that if you have a set of rules that have to be followed, the more people you need to get to follow them, the lower the chance it's actually going to happen. That's why as processes scale up, you start getting these people the developers see as a waste of time in the loop. In IT, it's system admins and whatever you call your security group. In medical research, it's data managers, who might not be trained to do the research, but can be meticulous about making sure the data bits are done right.
Personally, I'm happy to give out admin rights to people who use them responsibly, which I define as to do the set of things they told me they need them for, and then only in the furtherance of their actual job, not installing fluff crap they just want, like news(paper) readers. It's sadly a small minority that actually do this.
Really, both sides just need to listen to each other and show a little respect. We all just have a job to do.
I've been a software developer / consultant over 20 years.
With each installation we are given full access to our own pc/workstation and have full admin rights to development servers for the project. If production support is required, we are also given access to production systems as well, but this is more of an exception than the rule.
I recently finished a lengthy assignment with Union Pacific. There are many spart people there - but their security policies regarding developers is something from a TSA screener.
1. Developers do not have admin access to their own workstations even if they are required to design and test windows services.
2. Developers cannot perform any task which requires Admin privs on their own machine.
3. VMWare instances of XP and Windows Server are allocated and developers are given Admin rights to these machines, however the VM infrastructure is so overloaded - login can take 10 minutes or more ( in the DEV environment).
So - to answer your question - Admin rights NOT being given to developers is the exception. Only in large companies with paranoid and strict policies will you find this to be the case.
at my medium sized financial company, we remove developers local admin rights on their laptops and give them a VM to develop on/break.
There are programs where you can at least audit and try to remove some functions (Beyond Trust, etc), but really it comes down to too much work. We force strong anti-virus instead and use Websense to try to capture anything coming in from the web. Their build scripts temporarily disable real-time scan to speed up the builds. Engineers don't have a clue about protecting their systems, they may be smarter than the average Joe, but that doesn't give them an advantage when dealing with system security/updates/etc. In most cases they are worse because they are lazy about updates (yet cry when you force it on them), and they seem to think that everyone in the world is a straight shooter - "oh, we don't need passwords" or "we don't need to limit access". Give me a break...
Where does "production" - or any synonym, derivative or contraction thereof - appear in the post you're replying to?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
However, when I worked in a place where the development environment was Linux, no... developers did not have root.
File under 'M' for 'Manic ranting'
If you don't want devs turning off virus scanning then don't have it aggressively scanning constantly and don't use bloated junk that takes over the system. Virus scanners are huge productivity killers when not properly configured as they make systems crawl. Check on write and nightly scans are sufficient.
I turn that crap off too if it's preventing me from doing my job. It can be turned back on at night before I go home so it can do it's thing when it's not affecting my work.
Work Safe Porn
Officially, because my predecessor was too lazy to figure out a workaround for a particular limitation made relevant by the continued use of a decade-old IDE. A workaround it took me 45 minutes to find using ProcMon and Regedit. The real problem is that the developers (all but one of which are not trained developers, but are actually {unrelated discipline} students "trained" willy-nilly by a {unrelated discipline} professor that taught himself {old language} in the mid '80s), are intently focused on results, not process, and are too "busy" to have to remember that if they need to do something administrative, they need to Run As.. and provide admin creds. The whole concept of "admin" is curiously confusing to them; my boss constantly refers to "full admin" as if there were some hidden hierarchy. I constantly remind him that there is just admin and non-admin, and that when I do something particularly magical, it's not because I've granted myself "more" admin rights then I've granted him. It's just that I recognize the difference, and when to use one or the other. After four years, I think he's starting to get it.
Christ on bike, what are you smoking? And where can I get some?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Isn't that what VM's are for? Give them a sandboxed VM running the corporate image on a server YOU control. snapshots have them back to a pristine workstation after they are done testing.
On the dev machine, keep that restricted down to the core essentials for development, that way you don't have to worry about a dev system being compromised and having potentially harmful code introduced into whatever it is you are developing.
Keep the two separate I say.
Why should a developer have admin rights? In some cases, I can see giving them power user rights (for Windows boxes) or restricted sudo rights (for Linux machines). But no one should be running as admin for daily use. Most developers I've worked with were clueless about system administration (I say that as a developer) and most of them shouldn't be trusted with root/admin access. I do development on Linux most of the time and I don't need access to the root account.
Granted, a good developer will probably find a way to grant themselves admin access unless the system is really well secured.
I work for a very large U.S. Government Defense branch as a UNIX system administrator. Our workstation provider provides us development accounts which have local administrator access. Not only can this account make changes to the local workstation (as one would expect with an Administrator account), the account not required to use a SmartCard (CAC) for login. However, to gain this level of access to the system we are required to take an extra class (online) and go through an IA approval process every year. This workstation usually only provides me with e-mail, as my work workstation is a Ubuntu system that connects to our "management" network. This allows me to manage the systems on our local floor.
However the local admin access on my "e-mail" system has been indispensable on more than one occasion.
Yes for local systems, and that is using a wide definition of "developers" -- not just the professional software developers we employ, but also the people in "informatics" who are basically scientists who build or evaluate new software tools for data analysis, and the engineers who write software to control automated systems.
As far as I understand, this is against our own Very-Large-Company policy, and the threat of having administrator rights taken away is hovering constantly over our heads (now said to be a central IT goal by the end of 2010), but fortunately our local IT managers do understand that we need them. It wouldn't be worth the massive overhead of routing all requests for installation of new software over three different continents (I'm not kidding) and some people with difficult-to-replace skills would simply walk out if this was taken away from them.
There are always dire predictions of the disasters that will result by granting mere end-users administrator rights, but incidents are rare and usually easily resolved. Frankly, while it is true enough that many of the people with admin rights don't know that much about system administration, they actually know a lot more than the average helpdesk jockey who is in and out within a year, but can apparently be trusted with the powers to mess things up thoroughly...
Admin rights for servers we don't have on a personal basis, but on servers that are dedicated for specific purposes, some of us have access to service accounts that have administrator rights. If the server provides services to multiple people, the IT people are usually unwilling to grant that, and I find that understandable even if I don't entirely agree.
Pretty sure i know which company you're working for, as there's one such large non-IT corporation with a very large IT department that did exactly that in the roughly same timeframe with the same exception at the same time.... while I'm sure there's more than one, the wording used in the summary makes me think I'm right.
Anyway, most debugging tools and stuff will work without administrator right, the main problem is when comes the time to test out new software, like betas, and things not approved to be used by the developers, or when writing an app that needs full control on the machine for integration (rare that there's a REAL business case, but it happens).
In that case, said company will still make an exception, you just need your manager to say pretty please to the powers that be. I still have the exception, and will keep it, because we convinced the upper people that we couldn't do the job without it, along with ability to bypass the proxy and filters, the exe download blocker, and so on. Plus you can request virtual machines to be built for you.
Thats how anal companies work anyway. All other large companies i worked for still gave a lot of control to the devs on their boxes, give or take a few things, such as deciding whats the primary development environment and main development OS, but thats about it, and many are completly free for all, as long as you stay within the realm of legality.
They took our admin rights away for exactly one week and tried to give us only rights to those things that we 'absolutely' needed, network and workstation. In that week there was not one line of code written. We did nothing but put requests in to the net admins for installation requests, access to SQL tables, rights to servers ect...
We were obvious about surfing the net while our code refused to run correctly, and when asked what we were doing we pointed at the net admins. They took our ability to work away. I can understand not wanting us devs to have access to the production network, but you can't just drop us off the network and not give us test equipment.
They never thought of it this way, but basically their idea was to take everything away from us and determine what was 'absolutely needed' by how much we bitched about it. After a week of dev standstill while the net admins worked 16+ hour days with no end in sight, they gave in and gave us local admin rights with limited admin accounts to the servers that were fully off the production net.
The story does have a happy ending though. We're now have our own network that's 90% identical to the production network, and physically (no connecting copper) segregated from the production net. Granted most of our equipment is the old castoffs of the production net, but it just simulates load... or something. We can laugh it off when we accidentally forget about that truncate where 1=1; instead of hiding under the desk and updating the resume. And it only took about a year and a half to actually do it right, instead of flipping it over the weekend.
Needless to say yes we still have local admin. Maybe some places could take that away, but you had better have one damn good plan and a awesome team of crack net admins to pull something like that off.
Why would you want something to smoke, when you have your mouth on your tiny "pencil" already, & sucking voraciously?
With thousands of employees, the IT support guys have enough going on without having to come install things for me every time I need them to do my job.
Our development takes place primarily on a separate development network that has no connection to the outside world - it's a little closed loop and it makes for a great test environment and sandbox because of that. We don't have to worry about corporate restrictions, because development machines are seen as separate from a user's corporate workstation. This seems to me to be the best possible way to ensure that corporate security policies on corporate machines don't interfere with development requirements.
Here is my 2 cents. I do not think they should have admin rights to their local machines. These are workstations that are issued to perform a job and that is to code. Once your tools are installed there shouldn't be any reason to need admin rights. You should however have a virtual test environment with something like VMware workstation where you would have several OS's loaded in there one with admin rights to test your installs, and debug. Absolutly your application you are writing should be fully tested without admin rights. I cannot tell you how it burns me up to have a vendor tell me to give a user admin rights to solve an issue with an application.
I'd say if you are targeting a very specific platform, developers don't really need full admin access to do their jobs. e.g. ASP.NET development is fairly rigid and it's usually done with the whole team using the same exact tools (Visual Studio, TFS, etc). In such a regimented environment, it might be better to lock everything down. But in an agency or consultancy shop, the tool set could change with every project. I don't think IT should be on the hook for setting up random systems that will only be used for a few months or weeks before being torn down again.
Are we talking about kids hired at minimum wage to write javascript that animates the company logo on mouseover? Experienced C developers writing device drivers? C++ developers working on a legacy MMO engine?
"Developer" encompasses a very wide range of experience and knowledge levels. Experienced professionals working on complicated programs should not be encumbered by controls designed to prevent idiots from screwing up their OS install. Employees who barely know enough about the system to write business logic, should not be in a position to break things.
Developers have to write Administrative functions in code. For example: Its absolutely required that Developers be able to write the Installation / setup programs and test them. For windows machines, that means that Developers need rights to modify the Registry, startup scripts, Install System Services, End Task on anything, Set Security Permissions in NTFS, Modify User Accounts (such as adding icons to all users, or specific users) That doesnt mean, that the core program needs to run as ADMIN, but most likely, the Install/ Uninstall should.
In their own lab systems as they may deploy them occasionally in snadboxed network segments, they do whatever they want. In our formal development and testing environments, it;s a different story. We typically have 4-5 code migrations areas per application from: Unit code testing, system/load testing, Customer QA, Production, and occasionally a specialized environment. In the Unit environment, they have read/write access to most of the server, but this varies by OS. under Windows, they pretty much have to be admins (but not local). In Linux/Unix, they only have read/write/ex in the directories specific to their app. We have hardened linux images, and they can't access core functions or configurations outside of their app. In System environments, they're lucky to get read access (except in Windows environments where their access is the same as unit envs).
In QA, Prod, Training, or other environments, Devs can't even log in, except with the same credentials as a user that might use the system in production. An Operations team, dedicated application support team, network security, and a few other people have admin rights, but even our software deployment team looses their login rights once the system is put into production.
There is no contest in life for which the unprepared have the advantage.
your horrid writing skills identifies you as an apeman.
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.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Whether or not such a system is beneficial really depends on the developers. In the case where the developer is knowledgeable and - even more importantly - respectful of the systems he's entering (and those that maintain then), having a higher-privileged account for devs is great.
On the other hand, having a situation where devs are making changes to settings (of live systems), or pushing major code updates without a review process and/or using a repository (for rollback purposes) can be terrible.
It really, really sucks when you're an admin and servers suddenly start going berserk without you knowing WTF is going on, only to find that *somebody* made key changes without checking them in or having them reviewed, especially as you're the one likely to take the heat when it's "the server is screwing up again," when in reality it's "somebody uploaded bad code to the server and/or mangled a bunch of settings."
So for the devs out there, please be kind to your sysadmins and use a repository. The ability to roll-back will save you headaches as well as your admins. Also, if you're going to make changes to system config, check with the admins first, or at the very least let them know what's going on so if something going *boink* they can trace it down.
Folks in our department have local admin on our own PCs, but it's like pulling teeth to get InfoSec to grant it. (I think it requires VP approval for each PC). On the other hand, we are under no circumstances given root to our Linux servers, not even our dev boxes. Not even on virtual machines running Linux. This is a huge PITA. I can't count the times a five-minute change like adding an entry to tnsnames.ora has ended up taking hours or days to complete through the 'create a ticket' method. Even worse than slowing down mundane tasks, it stifles any exploration of alternative tools. Unfortunately, this sort of intangible 'innovation cost' will never show up on any objective cost/benefit analysis.
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.
I hate having to be extra-careful to make sure that I'm not in prod. I'd much rather just know that I have no access to production so that I couldn't make changes, intentional or otherwise, at all.
--Jeremy
Jesus was a liberal
I work in a government installation as a software developer and due to government regulations the only way we can install any software or anything is to either put in a request to the IT people to come up and do it, or our supervisors can get special permission to be allowed to install stuff onto the machines of the developers working directly under them.
See subject-line above, & rinse, lather, + repeat (several times, until it sinks in & you realize you're nothing more than an off topic, undereducated moronic troll). This isn't "english class", dunce. Realize that. Also realize that slashdot has no such section in its forums, nor is your reply on this topic, so you are truly nothing more than a trolling off topic ass.
I wasn't a full time developer (engineer, mainly, but I did support some avionics test stuff) and I never did Windows. So take what I say with a grain of salt.
I supported apps and system stuff on a half dozen *NIX systems. For development, I had several development environments set up on test hardware. I'd need root (admin) privileges to tweak the system config, install custom networking daemons, drivers, etc. But I had a plain old user account for use in testing modules and apps. I stayed off the root account unless absolutely necessary.
Meanwhile, I worked alongside a bunch of Windows developers. They all had admin rights, developed everything as admin, tested it as admin and turned it over to the user community. Thanks to their 'bad habits' there were more than a few circumstances where their apps would not run unless their users also had admin rights. Toward the end of my career at that outfit, there was talk about taking their admin rights way, or enforcing practices similar to what I used voluntarily.
I suspect (and perhaps some Windows folks can verify this) that there's a fundamental difference in the philosophy between being root on a *NIX box (a completely different user) and attaching admin privileges on Windows (same user, just more permission bits set). One thing that our Windows developer community appeared attached to was the ability (need? addiction?) to have access to their user space at all times when sitting at a desktop. Asking them to adopt a different user profile for developing/testing/installation/administration would have deprived them of the ability to do IE/Outlook, visit YouTube, etc. while their system was connected to some aircraft under test.
I shudder to think of how many times someone was uploading new (classified) firmware into a fighter in one window while IE was prompting them to install that mystery CODEC in order to view some 'important' email message.
Have gnu, will travel.
Developers actually help administer our servers and our network hardware. So far it's been a good experience, even with them administering our firewall/router. I have nothing but g....ATH++ NO CARRIER
At my last job, I wasted tens of hours on trying to get the IT guy to come down to my workstation and give me the local privileges needed to compile or configure my various IDEs. Finally he just gave up and made me a local admin and there wasn't a problem after that. (This was a Windows setup, BTW)
Two of the last three companies I've worked for as a software developer only gave us power user rights on our windowsXP machines. I was doing embedded software development and testing at both of those companies and it didn't cause any problems not having admin rights on my local machine. I could see where in some cases it would be impossible to function as a dev without admin rights but in most cases it can be gotten around by hiring smart IT support technicians who know how to install complex software and hardware and developers who can communicate their needs to the support staff.
To support the IT guys I'll give a recent example of how I effed up my Vista machine doing something that shouldn't have caused any problems. Vista kept bugging me about enabling automatic updates so I got annoyed and told it to download and install all the latest updates (no service packs). Well, that caused every single proprietary piece of software on my machine to crash on startup. It took the IT tech about 4 hours to figure out what happened and correct the situation and me another 3 hours to put my machine back to where I wanted it.
The moral of the story is that you have no clue what could mess up your computer and IT does. They've dealt with way more computer problems than you could ever in your entire life which is why they should be the ones installing drivers/software on your computer. Plus, you shouldn't be wasting your time developing your computer because you were hired to develop software.
Think globally but act within local variable scope.
Yes, we do.
And, yes, I've used it, at the Client's facility to get into the admin account of lab computers--with the Client's full knowledge and permission.
We need full access to our workpiece in order to work on it. IT officially doesn't support this, but the IT guys that support the labs know what we do, and what we need in order to do it.
At least that's how it was when I was there. I usually do a couple years on and a couple years off for that particular client. They may be totally locked down and outsourced to India/China by now.
"Reality is that which, when you stop believing in it, it doesn't go away." - Philip K. Dick
If you have decent developers and they have physical access to their machines (particularly laptops that they can take away from scrutinizing eyes), then they likely already have local admin rights in some form or fashion, whether you want them to or not. It's an asinine waste of resources to try and use an IT group that is usually less competent than the developers to police those developers' local admin rights when they have physical access to their machines.
If your company deploys a privileged password management system, then you can scramble admin passwords regularly (say daily) and implement authorization processes that allow people who wouldn't normaly have admin rights to production systems - like developers - to get them temporarily when required.
e.g., privileged-password-manager.hitachi-id.com
1. Developers shall not have root access to shared machines.
2. Limited root access is provided for specific functions.
3. Specifically, "sudo tar" works.
I am pretty sure there is some kind of subtle flaw here.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
My former employer suffered more than one very serious work-stoppage (lost scores of manhours) over the whole LAN due to problems caused by a developer whose Windows Domain account (and primary login on the local PC) has Administrator rights on the Domain and (thus) on the local machine. (This is due to Devs *not* being experts in networking, security, application and service mgmt, windows domain policies, etc. If they were, they would not have needed a Windows SA, right?) It was only after this fiasco that the mgmt folks acceded to my plan.
It was a lot of work to set up, and a lot of pain the first couple of weeks to train/handhold the Devs, but it started to really work. Oh, it should be mentioned we has somewhat unusually high security requirements due to being in the financial sector and handling customer credit/debit card data, etc. But, really, most of this was designed and implemented to actually improve work processes and uptime. And it did.
In Nature, stupidity is a capital offense. In human society, too many get off with less than a warning.
no local admin rights, but the admins are stupid enough to use default admin shares. the local admin account password can be cracked in a matter of seconds and it's the same on all machines, leaving the whole network open to great pillaging and plundering.
I work for an international company in the corporate department, and the way we do it is:
You have a corporate desktop meant to do corporate work, which means your Office suite is on it, you use the standard AV and other tools (standard image), and you're allowed to install whatever virtualization package your team is licensed for on it.
This seems to work pretty well for everyone!
With these bozos calling the shots, it took less than a year to turn a world-class development shop into a ghost town.
Like it or not IT pals, developers have to do things on their boxes that normal users should not be able to. If you try and prevent them you will force them to come up with even more dangerous workarounds (tunnels to home boxes, dark nets, etc). If you're worried about security isolate their network, but don't make it impossible to do their jobs.
Mordoc Rules: http://dilbert.com/strips/?CharIDs=15&After=01/01/1996&Before=12/31/2009&Order=s.DateStrip+DESC&PerPage=50&x=23&y=9&CharFilter=Any
Really several of those have happened here, and a couple of more from Dilbert[TM] that don't show up in that link. I thought Dilbert[TM] was meant to be a cartoon, not a documentary?
IT controls the virus checkers on all the machines, but they never keep them up to date for Windows, nor alow us to update them. "Linux is just a Toy" is a direct quote from IT. The other day a colleague told IT that someone had to move down from Mac to Windows, and ITs reply was "at least they didn't take even more steps backwards to Linux", but I digress.
After IT discovered the Virus, they declared, without any evidence, all Open Source Browsers, like Firefox and Opera, and Email programs must be ameliorated from all company computers, or you would be terminated. They then decreed that in the name of security only IE6 and Outlook would be acceptable for Internet access for any reason (so much for using any other ports, those do not exist per IT). Makes lots of sense to force the usage of the two most attacked programs in the history of Mankind in the name of security. I've about given up on Internet at work and do most of what I need at home now.
IT always says "we must protect The Server". If The (Windows) Server is so vulnerable that it needs so much protection, why do they keep using it? I've asked to be removed from The Serve as I don't use it to do my job other than for backups, and IT says my source code backups are to large and want them removed (WTF?).
I develop Embedded Systems. Right now I'm trying to write a USB driver for a AVR, that has to work with Windows, but IT says I don't need Admin Rights. Boss says "do what IT says". Guess I'll just tell the customers "sorry I could not test this, talk to the boss or IT if it does not work", as I'll have no idea if it works. Its a small company, telling me to talk to someone higher up won't help. Resume anyone?
Large corporations often standardize workstation setups in an effort to:
Developers usually need admin rights to a workstation or VM somewhere in order to develop and integrate applications. For our last project we used COE workstations and developed our apps on a VMware, then used the COE environment to test functionality. We ended up needing admin rights to 1 'dirty' workstation since our integration was going to require a change to the COE, but we kept the rest clean.
The funny but sad part was the COE was not as standardized as we were led to believe with COE workstations sporting different versions of Java and IE which caused some interesting problems.
All developers I work with uses Linux :-) But then I'm lucky.
Well the first problem I see is that your on a Windows platform, so security is the last thing you'll be able to enforce. LOL Windows also has a horrible user and group permissions system, so relying on that will also include many headaches and issue in your future... continually. Can't really help you in Windows world beyond showing you a hack to get around pretty much anything - thus why I say not to even try. I've worked at companies that freely gave out root access to developers, and others that guarded access like a trade secret to their special formula. Ultimately I don't believe developers really need root access, but that is dependent upon having a system admin that is doing their job correctly, and also definitely helps to use a code revision repository (SVN or CVS). I've also found that just building a local environment when restriction are in place, allows me to do anything I need, as master of my own domain - okay, crappy outdated workstation. But in either scenario, administrative or root access isn't necessary. Is it handy to have? Certainly, and has helped in the development process, but necessary, no. I also believe though that if you don't have developers that are capable and that you trust, then you should reconsider who works for you, and as a result should feel comfortable allowing root access. Any developer with ethics, even if parting on the worst of circumstances, isn't going to sabotage the system or server. The tech world after all isn't really that big of a world, and everything always turns full circle sooner or later. At least that's my two duckets worth. -Davey
You can have my root password when you can pry it out of my cold, dead hands.
We can admin our windoze machines to install stuff and such, but the domain control rests in our IT dept (2 guys for 140).
The several "public" linux machines I develop on and administer have a common root password, except for my "personal" machine, which I keep. All the stuff they'd want off of it is in perforce anyway, so it's not a big deal.
"Sometimes the truth is stupid." - Lawrence, creator of Prime Intellect
The image looks like the production image, but with the various tools installed and a somewhat more liberal group policy.
And they are admins. They have access to the development network too.
But those systems are shut out of the production network.
I'm currently working as a developer for a major player in the mobile industry. We're local admins on our windows boxes, but we're switching to Linux now, and are not given the ability to su our own linux boxes. :-(
If you don't trust them with the rights, they shouldn't be working for you.
---- Booth was a patriot ----
And when you develop mostly AD integrated apps lets see how your isolated VM works out for you.
---- Booth was a patriot ----
By default OS's are (or should be) designed to not need admin/root rights for most of the tasks. Only real admin tasks needs those.
As for developement or running a service/program/whatever it will be possible to write code that will simply be run as a user (Although it is often started as root and then forked to a user). This is better for the security and it will still provide you enough rights to do what is needed.
At my Very Large Corporation our developers need admin rights because we are constantly tinkering with special hardware, updating drivers, running software that's not supported by anyone (obsolete compilers and debugging tools in particular), etc. So we have admin rights. However there are some corners of the org where this is not the case (mostly not in the US). The devs in these corners get their testing done by running unrestricted private installs of Windows inside VirtualBox. We have ready-to-run disk images on our servers for restore if something gets hosed in one of the virtual environments.
The same problems are at US Bank.
I wonder if it's just some douchebag consultant or lame security guru in Minneapolis laughing all the way to the bank.
Target and US Bank are both based there. Is Best Buy that bad too?
Comment removed based on user account deletion
If your developers can't figure out how to get local admin rights on a machine they have unlimited physical access too, then perhaps they shouldn't have those rights. They don't need network admin rights, but even at Oracle I was able to capture the network admin password just by writing a program to monitor remote access by the sysadmins.
Our Devs have full admin rights....on the Virtual Machines they develop on. It's great, they create a base VM, store that drive file as a template, then do their development and testing. Anytime they want to, which turns out to be a couple of times a month usually, they delete that active VM and start over clean from the base. They can also run multiple identical VMs side-by-side if they need to.
Need to test against a different OS or a server? Create a VM for it and go. Doesn't matter if they trash it, it's just a VM.
-B-
Developers must be local administrators to: ...
- Manage local services (Ex: SQL server, COM+, etc.)
- Register/unregister COM objects; Add/remove objects from the GAC; change the strong-naming settings,
- Attach the debugger to a process
- Change IE security settings
You can actually attach a debugger if you are in the "Debugger users" group but there's no sense in removing local Administrator rights from a debugger user because the debugger can be used to execute privilege escalation attacks. So all you do is make it harder for the developer, without buying you any security.
I completely own my linux box at work (root and all), and I have admin privileges on my XP desktop. There are a couple company tools that IT pushes and updates (like antivirus), but I can install and run anything I want. It basically boils down to us wanting to get work done, and if I had to wait for IT to install everything I needed when I needed it we'd be a month behind on the latest project instead of two weeks ahead of schedule. This comes with the expectation that if I do something stupid like start torrenting porn from my work computers that I will get slapped hard, and that's fair enough.
So that seems the way to go: allow devs admin privileges and fire them if they're dumb enough they can't handle that. This is win-win for dev and IT, unless IT is primarily interested in empire building. Everything else is just a doomed hack around the fact that you hired bad people.
I also work for a Very Big Corporation. Shudder. I was tols I could develop applications under the following guide lines. No access to toad. No IDE. Only what was offered to Office workers. No admin rights locally. 1) Submit the criteria of the app. 2) Build 25% of the app, but don't run it. 3) submit this 25% for security verification (4-6 weeks) 4) Build the next 25%... Etc till the app is 100% Then submit for one more security review. Then allow the end user to see the application with the first run. If they dont like the application? Return to step 1. I finally got access to Admin and usually bypass all of their restrictions and can get the job done. Sheer incompetance.
CmdrTaco: I have been on all three levels: developer, desktop administrator for developers, and server admin for developers. From my experience, its easier to do it on a *nix environment vs. Windows environment - that's not to say it can't be done. If you have a good Windows Active Directory Administrator, you can set up GPOs that allow developers to have the necessary rights to develop and maintain applications in a production environment. The biggest pain is getting the developers to change their habits. The way that my department implemented these accounts on the Windows side, is that we created separate accounts. So, say for instance, your username is foo. We then would create in Active Directory an a_ account (i.e. a_foo). That would be your admin account. We then would create GPOs to access the correct registry information in Windows to allow debugging, installation, etc. on that machine. Since, we have GPOs on a group of machines, if we needed to use any of those GPOs on the server environment, we could do that as well. Once we got that set up, and educated the developers on how to use their a_ accounts, they were able to develop and maintain the production applications in Windows with no problem. And if you wanted to use the same type of administrative structure on any *nix system, you could use PAM and sudo controls to give the developers the flexibility that they need. Hope this helps... IMO, when developers have total control over production machines, its because management doesn't understand how admin controls can be separated from users, and the developers aren't open to a "change".
yep, seen it a lot. And its BAD. Its usually done because whiney devs (interchangable with "application admins" and "DBAs"), who don't really know what they are doing, claim that they "need" root or admin access in order for them to "debug" and diagnose problems... without actually being able to specify or provide an example of said activity, thereby avoiding the use of targetted or ad-hock sudo access to do the same (a much safer and sensible option, even allows you to document what they are doing and why, for things such as upgrades/migrations...). The incessant whining usually results in management saying "just do it".
The end result is usually a combination of:
- services running as root/local/(or heaven forbid) domain admin
- deployment instructions that are full of the words "as the user root/local admin" for no apparent reason (e.g. chmod a file as root already owned by the application user??)
- the scattering of random application libraries/binaries across system filesystems/directories
- the implementation of chunks of applications using pointless system calls to unmaintainable standalone binaries that devs have scattered across the filesystems.
- insert your own nightmare for system maintenance......
Separate vlan, virtualized or build with premade images. Contains independent management structure which assumes admin level rights for priviledged users. Remote access via client software (it's pretty easy with virtualized vlan, however for many purposes RDP is sufficient).
The vlan is separate from company environment apart from remote access. Hosts located within VLAN can be reimagined at moment's notice. Snapshots can be taken at developer's request.
It's not that difficult to set up, but you need to do some preparations in order to have fully functional disaster recovery for this vlan, along with snapshot capabilities and consistent monitoring.
You may also want to have update procedure to ensure that development environment (and its base images) is not out of touch with real world.
Also, you need to cover your bases with regard to licensing and activiation (some O/S requires special provisioning).
Regards,
Ruemere
Well... when PIPBoy3000 says, "We're local admins of the application servers, and a couple of us have domain admin rights"
I take it as; A) the 'application servers' he speaks of are 'production'. In the most general sense people call their production servers 'application servers' because their applications run there. Personally, I take it as the application tier of a n-tier system with no mention of the webserver tier or database tier. But that's just how I have managed to convert 'lamer speak' to actual architecture over the years.
And B) the 'domain admin' rights would tend to describe the production environment, unless this fellow is in a really grandiose Forest environment with multiple domains. I doubt it considering their using shame as a change control methodology
So, my question to you, Hognoxious, is how could you NOT get that from what was posted?
Wherever You Go, There You Are
I'm the IT security director for an international company (35+ countries). We have a variety of user / developer and security requirements.
We do not give our developers local admin on there workstations. However, we do give them VMs to develop on. This way, if they screw something up (which happens a LOT), they can go back a snapshot or two and fix things.
Incidentally, the test environments have very restricted security permissions - they have to be able to run on the federal desktop core configuration - so we encounter a lot bugs because developers insist on running their app with admin rights.
if we could train developers better, and have IT admins that understand both sides of the issues - things get better. It works pretty well for my company.
"Omnis tuus capsa sunt inesse nos"
Developers have total control over their workstation and "Sandbox" lives there in a VM. Developers have limited rights to the "development" environment where they can test things like deployment process and make some changes. In TEST, they have no rights (can't even login) and in PROD obviously no rights. Patch also often exists and is used by SA's only. I work for a large university where we support a lot of different apps in a fairly heterogenious environment not one or two products like I have in the past in corporate environments, it works well IMO once the developers get the idea that they have to get things mostly right before moving into DEV.
it's simply impossible to do your job otherwise
Where I work, we do development under Windows XP. Our Active Directory accounts don't have local administrator access, but we know what the password for the local Administrator account is, so when we need to install some software, we can just "Run As...".
There are various tricks that make this work better, like running Windows Explorer as Administrator ("explorer /separate"), using Tweak UI to make the toolbar of Windows Explorer appear different when run from the Administrator account, knowing how to open various Control Panel applets via their .cpl files (e.g. "appwiz.cpl" gives you the Add/Remove Programs, if I recall correctly).
I find this much nicer than logging out and logging in using the Administrator account because I don't want to have to close all my editors, my email, etc. It seems to be a good solution 99% of the time.
For developers working on programs drivers and tools that require it for testing yes. It is possible that some have no control over their desktop by the second system for testing requires full access. Try and install a program on windows without administrative rights... Can't do it.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
Developers should have admin rights, but programs should be able to install without admin rights unless there is a darn good reason to have admin rights. Maybe if developers were forced to install without admin rights, then software installation on locked-down corporate desktops wouldn't be so painful.
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.
I have to disagree. That's what a staging environment is for. Your analogy would be tantamount to making a car manufacturer build every automobile sitting in the passenger seat with the door closed.
My group maintains and enhances an operating system. Obviously, we need full access on the machines we debug on. We also have separate "production" machines used for builds and source control where developers don't default to having admin privileges (and admin privs are generally reserved for the people less likely to break things). We used to give all the new developers admin privs from day 1, but that almost led to a few disasters (new people with full admin privs on an unfamiliar OS is not a good idea).
We generally try to let the admins take care of the production systems and only take over when they aren't around (it's only two people). And we let them know what we fixed because we appreciate the fact that they are normally dealing with it for us...
OTOH, one doesn't need any sort of special access to develop simple applications on decent operating systems like Unix or Max OS. One only needs special access when one starts installing shared libraries, doing kernel work, or setting up shared source control systems (although, it's generally not a good idea to let all the developers have uncontrolled access to the source control system, either).
An engineer who ran for Congress. http://herbrobinson.us
We all had local admin rights until about a year ago. Under the new policy, standard user logins do not have local admin rights. If you need to install software, you need to login as a separate poweruser, which in turn disables access to all network resources (drives, printers, etc).
It was a big pain, and people did a lot of bitching and moaning, but slowly we're getting used to it.
There are several options:
1.) logout/login as poweruser
2.) Right-click, do 'Run As'
3.) While running as local user, open a CMD window that's running as poweruser.
-Mark
There are 10 types of people in the world; those who understand binary and those who don't.
These days developers do not need admin rights to physical machines. All they need is a user account with permission to launch virtual machine instances. They can have admin rights on the virtual machines.
At my company we've been developing software for solaris for over 10 years. We develop and do some testing on solaris workstations, without having root privileges. This has been working fine for a long time. If you need some new software installed, it is still possible to do it without being root and if you need something installed for everyone, it is better to ask the admins to install it, because they will also maintain it for you.
Lately we've be using Windows as well. Every Windows developer machine comes with local admin rights, because it would be too difficult to get anything done without it.
Yep, all our developers just delete the 'standard workstation', install Ubuntu for actual work and then install a stripped down Windows version in VirtualBox for all those pesky Windows-only reporting tools and IE-only corporate websites. The local IT staff is pleased - they don't have to support us beyond the domain password reset once every 3 months that we have them ask to do, because noone of us has a machine in the actual domain.
You want to be taken seriously? Prove you have a PHD in English. Not that it would matter though. Writing and who likes it or not is like resumes. 1 person loves your work, others don't. That's the way it is. I know You have no PHD in English, and none of you are experts on the subject of how to write because of that much. So who the hell are you or yours here to give anyone any advisement on how to write, or, what good writing style is?? Get over yourselves, please. You don't have what it takes to tell anyone how to write or write well. I severely doubt any of you has even achieved a single collegiate degree in fact. Let's see what these geniuses have to say about that much. It ought to be amusing, considering the idiot savants around here tend to sling a lot of advice, especially on writing (which is completely off topic, and slashdot has no 'english writing section' period especially), but they often don't possess a thing that says they can write well or have proof they themselves have mastered English academically.
"Any software that has its quality determined by what the developers test is crap anyhow. You make a fine argument that QA should test using non-admin accounts, however" - by lgw (121541) on Thursday December 31, @05:01PM (#30610308)
Coming from an idiot who couldn't code a program to save his own life like you? It's not our fault you are the dolt who can't pass a computer science degree. So, give us a break moron, and shut the hell up you pitiful retard. These "big talkers" are usually dolts who don't (and can't) write solid working code to save their lives and it's so amusing to watch them try to "play expert" like some "armchair quarterback", like lgw here.
The first thing i did when i joined a new company, is request that format my windows machine into a linux based one.
The request was granted to me because i was a developer, if someone else had asked it would have been declined.
Since it was a small company i offered to format it myself, Management asked no questions and allowed it.
So i have root access to my machine.
Why go through all of this? What happens if the production machine or even the site is destroyed? What happens if everyone in your building is hit with some new bug that kills everyone or the building being built badly collapses and kills everyone? I have also found it is very useful to have these records. Even for projects that I did 10 or 15 years ago I can't remember stuff any more. It also comes in useful if something is set wrong. Was it that way to begin with or did the software upgrade break something? I've put people from some very large organizations on the spot because I could pinpoint when something was changed on their part and not documented.
Finally, it is good to keep developers off the production box. They may put something on there that they are not supposed to. I know, I used to do it and so did all of my other developer friends. That stuff has been known to be used by attackers.
Oh. A couple of obscure American laws. How quaint.
http://developers.slashdot.org/comments.pl?sid=1495254&cid=30616776
Take a read there... but, Since reading is difficult for your ADD/ADHD or Dyslexia addled brain, I'll quote another person's opinion on 'writing style' for you:
PERTINENT QUOTE/EXCERPT:
"In other news, people have personal preferences, just as they do in the literary world. Some people like Ayn Rand, others hate her. Some like Stephen King, others hate him. Not so much their stories, but their writing styles."
So, like was said here earlier? Maybe, JUST MAYBE, when you get your PHD in English?? Then, & only then can you comment on others' writing style & be so arrogant to think you are somekind of expert in writing... and even then it wouldn't matter, as it is only a matter of YOUR UNQUALIFIED opinion only, & purely subjective.
APK
P.S.=> Amazing, all these "literary geniuses" here, that don't possess a PHD in English, & yet they see fit to critique others' writing style (especially since that is off topic, & there is no "English Grammar & Spell checking section" here on /., period)... unbelievable. You, & those LIKE you? You must think rather highly of yourselves, but, you really don't have anything that states you are indeed, an "expert" on writing... period! apk
http://developers.slashdot.org/comments.pl?sid=1495254&cid=30616776
Take a read there... I take that back though, since reading is difficult for your ADD/ADHD or Dyslexia addled brain, I'll quote another person's opinion on 'writing style' for you:
----
PERTINENT QUOTE/EXCERPT:
"In other news, people have personal preferences, just as they do in the literary world. Some people like Ayn Rand, others hate her. Some like Stephen King, others hate him. Not so much their stories, but their writing styles."
----
So, like was said here earlier?
Maybe, JUST MAYBE, when you get your PHD in English??
Then, & only then can you comment on others' writing style & be so arrogant to think you are somekind of expert in writing... and even then it wouldn't matter, as it is only a matter of YOUR UNQUALIFIED opinion only, & purely subjective.
APK
P.S.=> Amazing, all these "literary geniuses" here, that don't possess a PHD in English, & yet they see fit to critique others' writing style!
(AND, most especially since that is off topic, & there is no "English Grammar & Spell checking section" here on /., period)...
Unbelievable.
You, & those LIKE you (trolling undereducated idiots that have nothing better to do, and doubtless have not achieved a single thing worth noting their entire lives, especially if noted by others as good)?
You must think rather highly of yourselves, but, you really don't have anything that states you are indeed, an "expert" on writing (or, probably ANYTHING ELSE as well)... period! apk
Development environments are often shared, then please do tell me how ensuring those environments are available for everybody is all of the sudden an act of selfishness.
Sys Admins are paid to pay attention to the big picture, developers in general have a narrow point of view of things and often fail to appreciate how their actions can affect others.
IANAL but write like a drunk one.
"Developers DO need full admin rights on their dev boxes"
Nope. That is not needed, many big companies can and do internal development with full segregation of duties between developers and administrators.
There is no reason for a developer to be restarting a server, if he is developing on that basis you need a better developer.
IANAL but write like a drunk one.
Developers write software. That is it.
They should understand about resource constraints but that is all.
They don't need to understand all the intricacies of configuring systems in a complex environment, most silently security, or know about the latest and greates patches and gotchas going on on the system.
If I have got a penny for every time an application required to run with a privileged account unjustifiably, only because the developer worked as a privileged user all the time, I would have quite a bit of extra money by now.
That is the reason the two specialisms have evolved.
IANAL but write like a drunk one.
Which ones?
The limitations were in the developer's side for not knowing the implication of running everything using privileged access.
IANAL but write like a drunk one.
Unless developers assume responsibility for the security for the infrastructure they are working with, then they should not be given admin rights.
My ass in the fire? Then the admin password is mine only.
When developers join a firm there should be a standard set of utilities used internally which the developers must use. Developers should not pick and choose whatever they want, that is a recipe for disaster and a technological nightmare. And what about the licensing? Are the developers going to report all the software they install accurately for licensing purposes (even good admins have problems with this at times).
In return development teams should have speedy service, and once a tool is identified as essential it should be installed promptly.
But give admin rights to developers? Nope.
IANAL but write like a drunk one.
For applications that unwillingly (or willingly) stage DOS attacks (I have seen this against services as varied as NTP, NIS+, DNS and DHCP).
Can you swear that no developer will start a little DHCP or boot server of their own.
Guys, some of you are far too naive to be working with computers. At times I think it is a real miracle IT infrastructure works at all.
IANAL but write like a drunk one.
I would have identified the offending programs next day and had a serious disciplinary talk with your mate.
Nowadays there are plenty of tools to audit machines to stop these kind of shenanigans.
IANAL but write like a drunk one.
It is no wonder that computing is the cesspool of insecurity it is, when most people in this thread find all kind of inane justifications in order to jeopardize the companies they are supposed to be serving in a professional manner.
Many people on this thread claim that they can't do their job without admin rights of some kind, which is patently untrue:
- Do you need to install an application? Then ask your Sys Admin. Too much work for them? Then reorganize how the Sys Admin deals with development support. Ain't going to happen? You are working in the wrong company then.
-I need to install X,Y or Z application, library, whatever.: No, you don't. Refer to the list of approved software and use that, if some new software is needed then follow the procedure to get it included into the list. The procedure to get hold of new software is too long? Fix the procedure, you installing random stuff from the net is not the fix.
- I need a program that requires elevated privileges!: use a different program, the one you are using now does not care about the safety of your IT infrastructure, if this is not possible pick the damn phone and ask the software provider to fix the program, if they don't fix it expose them t public ridicule. Again, you don't need privileged access.
I have worked in many shops, both big and small, where people were reluctant to let the privileged account go (the real reasons were normally more mundane: could not download the latest and greatest games, could not use an arcane utility that was unmaintainable, you name it). Once appropriate policies and levels of support were in place the need for privileged local accounts became non existent (and the instances of security problems decreased dramatically).
Giving privileges to anybody but the sys admins is a sure way to create nasty problems.
IANAL but write like a drunk one.
It all depends on the questions:
-How can the developers do the most work without being limited
-How can I reduce the workload of the system admins for those guys
For some kind of development, it can be done with normal limitations.
But other kind cannot. And you'll have to find a suitable solution to work with.
For example: separate machines, virtual machines, give the local admin rights on their regular machines, etc.
There will always be a conflict between the needs of a developer and a system admin and most of the times they do not take the other needs into account. :)
As a webdeveloper I had a webserver running local on the usual port 8080. I was not amused when the admins installed a new virusscanner with build-in server that uses the same port. I had to have the privileges to change one of those servers. Without local admin rights I would have been unable to do it and that would mean I am unable to do my work (= useless spending of money). I don't think management would ever want to see that!
Preferences indeed. The preferences of employers matter much to those of us not independently wealthy. The preferences of senior engineering staff (you know, us old guys) matter much if you want to succeed in engineering. In any sort of professional career involving working for others credibility is key to success, and expressing your ideas clearly and persuasively in writing is needed for any sort of credibility.
Or, in onther terms, ZOMG fail lrn2Eglish!
Socialism: a lie told by totalitarians and believed by fools.
I'd always joke with people, saying that my job would be a whole lot easier if we could just keep all those pesky users off the servers. The reality of it all is that (obviously) without the users, there's no need for the servers, and therefore no need for the admins either. The admins provide an appropriate space for the users to work in, but also have to be able to maintain control from the standpoint of "IT practices". Developers have different goals than admins, but I don't think that means that they don't see the big picture. I think it means that they just see a different big picture than the admin. I've worked with a number of developers that were more than competent at managing the system as well as working the development side, but corporate practice forbid them to perform admin functions. When it's come to restarting applications or installing application libraries or anything of that sort, I've had no problems with developers making the changes as they need to. The difference is that they would have privileged accounts to allow those changes to be made, but not to make changes to the Operating system or to restart a box. Those practices generally fall outside of a developers normal set of responsibilities. Now I've worked in environments where developers have had full admin rights on their systems, but at the same time, that was also part of an informed management decision, which also removed my responsibility for those particular systems. The admin is ultimately responsible for the health and well being of a system, not the developer, which means that the admin needs to do whatever is necessary in order to ensure that system integrity is maintained, while also allowing the developer as much access as is feasible within this context. More often than not, this ends up being a compromise that neither the developer or the admin is happy with.
At one of my jobs, I was given a laptop, with the full expectation that I would erase the Vista partition and install Linux. At the other, I was given a desktop with a blank hdd, and a day to configure it.
have you read the Moderation Guidelines Addendum?
I had admin rights at my previous job, and I started a new job last monday with admin rights by monday afternoon.
RTFM is not a radio station.
As said before, any developer who can't administer their own machine is not a good developer. I've worked with several who were so ignorant of their OS that they would send a request to Help Desk to do menial tasks like install service packs or partition their new hard drive. Really? Come on, one woman didn't even know how to install her OS from scratch on a new machine. She was waiting for someone in IT to do it for her, I said "Uh, why don't you just throw the Windows disk in there and do it yourself?" And she says she doesn't know how. WTF.
The common factor with these devs is that they also coded very poorly, did not understand what the system was doing for each line of code, were completely ignorant of why you get different performance with one line of code that makes a DB call, reads a file, or simply increments a number. I tried explaining that it doesn't matter how fast your CPU is if you're waiting for a lengthy DB query, I get deer in the headlights look.
Bottom line, a dev who can't administer his own machine is not a real geek who grew up building machines and learning everything about them because he loves it - they are the product of Computer Science classes and know the bare minimum they need to know to put code together and make it do stuff. Someone who decided at age 20 "Uhh, software devs make good money, I'll do that." I don't want any devs like that on my team.