Slashdot Mirror
Linux in a Business - Got Root?
greenBeard asks: "I work for a government contractor, and have recently convinced them to purchase a Beowulf cluster, and start moving their numeric modelers from Sun to Linux. Like most historically UNIX shops, they don't allow users even low-level SUDO access, to do silly things like change file permissions or ownerships, in a tracked environment. I am an ex-*NIX admin myself ,so I understand their perspective and wish to keep control over the environment, but as a user, I'm frustrated by having to frequently call the help-desk just to get a file ownership changed or a specific package installed. If you're an admin, do you allow your users basic SUDO rights like chmod, cp, mv, etc (assuming all SUDO commands are logged to a remote system)? If no, why don't you? If you allow root access to your knowledgeable users (ie developers with Linux experience), what do you do to keep them 'in line'?"
I usually write kernal modules that nerf certain permissions.
This way, users can do what they like, but they can't fsck anything up.
Failing that, I reckon a big man with a large knife could probably go a long way to keeping them in line.
Me failed English...
FreeBSD over Linux. If my comments seem odd, this may explain...
Ever heard of setuid root?
ACL's are quite nice and so are different levels of security.
http://saveie6.com/
IMHO, this will depend on the environment you are running. If you have some development servers, your users are most likely to be developers, who will require full (or close to full) access to the servers. In your staging environment you may want to start logging all the commands, and provide only limited sudo access. In your production environment - why would you have users in the first place?
Sarbanes and Oxley. I don't know you, you don't need that access, we have a process in place and I am not signing off on you. Follow the procedure or go somewhere else to work.
Strange women lying in ponds distributing swords is no basis for a system of government.
The next time that server blows up and needs to be replaced, or we simply decide we need to add another one, building it is my problem, not those developers'. And it's a whole lot more problematic if I don't know all of what was done to get it into its current state.
Of course, that really just goes back to the fact that you should never do anything adminnish directly on a single server, ever. Your configuration management tool should do it for you, so it will also know to do it to the next one.
I come from the other side of the fence. I am a developer of multiplayer servers. For my part, I couldn't do my job without root access. I need to do things like set the date and time on the machines, install to /bin, upgrade compilers, etc. If I had to ask the helpdesk every time I needed root, they'd just set up right outside my cube.
On my Windoze machine, OTOH, I have no need for system level permissions, and I don't ask for them. I can install software, but so can all the other developers (and, I think, anyone in the company). All I use that machine for is e-mail and testing client connectivity to my servers, when I'm not using my Linux test client.
Some people need root and some don't. Don't make blanket policies unless you're prepared to make exceptions. Oh, and, for everyone's sake, if you do restrict access, please, please make sure that at least one person who can change things is available 24/7. I can guarantee you that Peterson up in Accounting is going to have a system crash that requires help when trying to get the year-end reports out at 2:30 A.M. before the big board meeting at 9:00.
... I'm special and rules don't apply to me.
How can I convince others of this?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Even the smart ones. Sure, give the users some stand alone development machines with root access but don' let them fuck up the cluster/servers. A lot of users are focused on their job but they don't always see how their actions on shared equipment will impact the company or entity at large. /tech support at large lab, full of brilliant idiots.
I drank what? -- Socrates
(Disclosure: I work for Sun and work with Linux since 1994).
Why would you move the modelers to Linux from Solaris? There is no real advantage....
Sure a Beowulf cluster is a nice piece of hardware, but hardware can only compensate a bit for programmer productivity... If their code is written using MPI or OpenMP or some other standard clustering environment then there shouldn't be a need to move the developers, should there? Just recompile and go.
It is really much more efficient to shove faster hardware under a programmer then to force the programmer to adapt to a different programming environment. Programming for a cluster is hard enough without having to take into account the details of the operating system, forcing them from Solaris to Linux might improve the execution part (on a side note, have you considered Sun's clustering tools?). But it *will* set them back in productivity while they move to different compilers and adapt the execution of the program to the Beowulf environment.
In my opinion you have forced your customer to make a move on questionable grounds.
Now to the matter of security. As you are aware, Solaris has the highest level rating for security. Secure Solaris is the defacto operating system at a number of government agencies. Linux cannot hold a candle to the multiple access levels of the Secure Solaris operating system. You state that you are frustrated at needing the helpdesk for file permission changes. What is your point? Are you using the fact that YOU don't like the limitations to change a customer from Solaris to Linux? Or are you complaining that the customer's environment did not deploy secure solaris with its multiple access layers? In Secure Solaris there is no need to muck with sudo. Each file can be managed properly from a security point of view (come to think of it, much of that can be done with Linux too).
Before I answer your question, let me state that I understand your point of view. When I joined the navy as a UNIX project manager, the admins gave me absolutely no rights whatsoever on the production systems. Their reasoning: '.. he can do things I don't understand, can't control or prevent.' There will always be a tension between the lockdown desired by the admins to keep their environment safe and secure and the users who want total freedom....
In my mind there is NO good reason to give ANY user root access in a secure environment. Period. If you have frustrated in the past by having to interface with the helpdesk, then the helpdesk needs to be improved. At the same time, I assume, any user has full access to their files.
You mention that you have convinced modelers to move to a Beowulf environment, then why the issue anyway. If they run cluster code then they run as user. All the need are basic user access rights, nothing more...
Maybe I don't understand your point....
I also work for a defense contractor and adhere to strict security rules. We have a fairly simple means of controlling our developers who need root access. We buy their systems using their bosses' overhead or project charge numbers, place them on a monitored, isolated subnet and, when they hose the system, all time expenditures are billed to one of the previously mentioned charge numbers. At my billing rate, it doesn't take too many incidents for them to feel serious heat or be canned. Either way, they do not touch production machines or cause problems that cannot be quickly isolated by disconnecting the subnet.
It works for us.
I've been both a developer and an administrator.
/usr. root access as we know it is a luxury that should be reserved for true administrative duties, unless absolutely positively necessary.
As a general policy, if a developer needs root access, they need to prove to me as an administrator that they actually do need root access. I'm not going to give root access (sudo, su -, or access to privileged accounts), even on a development box, to someone that needs occasional chmod privileges. More often than not, the people who are begging for root access are those that have been so spoiled by coding on their own Linux boxes that they lose sight of all the best practices that contribute to good code. They want foolish things like directories with 777 privileges so they can drop temp files when there are 30 better ways to do it. root is not a cure all... just because you're used to it on your own machine doesn't mean it's appropriate for coding in a multi-user environment developing customer-facing applications.
In the end, there are very few specialized applications that actually require root access to work. I will concede that sometimes root access is necessary but it needs to be treated on a case-by-case basis. I'm of the belief that a properly written application should be written such that it can be run with the least amount of privileges, and can be installed anywhere... not just
Good thinking using both forms of the term duck/duct tape so as to avoid any potential flames about spelling it wrong. You, sir, are a born diplomat.
Of course, this being Slashdot, the more likely scenario is flames coming at you from both sides. Good effort, though.
Good for you. I don't give myself privs on the system (I have a separate account for root-access), and I'm certainly not giving people who aren't familiar with all of the ins and outs of a production system access. I am most certainly not giving developers, who have a tendency to muck with libraries and paths to solve problems, access, even if its logged. Being able to yell at the specific miscreant later really is poor compensation for having to take a production system down, repair their handiwork, and deal with the rest of the angry users.
/Users directory tends to raise sysadmin blood pressure, as does nuking /etc, thinking it was ~/etc, or updating a system library to fix your program, which then breaks production codes that people are actually using.
I used to deal with this on our production cluster all of the time. I implemented a pretty rigid policy early on, which was no root for users on anything that was (1) in production, or (2) had access to the various network servers. This policy came about after a few 'experienced' users demonstrated their skills. Accidentally changing access privs and ownership of the
The problem always seems to be that people who've admined their own, solitary, system, think that experience automatically translates into full privs on a much larger, integrated, environment. This is where I miss VMS, and its fine-grained privs. I'm not sure I'd hand those out either, but at least it's better than all or nothing. The next best solution is giving developers access to a box that you can nuke and reimage back to a standard state, and letting them hack with that.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
Why in the world do your users need root access? On Windows it makes sense; all too many poorly written programs refuse to install or run unless they can run roughshod over the entire system. But this is Unix. It's a rare piece of software that can't be installed and run as a user. Most can even be installed as a user but made available to others. Yeah, it's a bit more frustrating that you can't just install the latest RPM, but if you're skilled enough to install an RPM, you can probably manage "./configure && make --prefix=~/mybin && make install". Changing file ownership? Again, why do you want that? If you're sharing files with other users, get a group set up and chgrp the files appropriately. If you have lots of complex sharing needs, set up one of the Access Control List options.
Ultimately users shouldn't need root. Professionally I development clustering software for Linux and other Unix systems. I regularly install new applications I'd like to use in my home directory. Our administrators set us up with a good ACL system (courtesy of AFS). I do the cast majority of my work as my own account. The only time I need it is to test root-specific aspects of our software (if launched as root, it runs jobs as the user who submitted it). I can't remember the last time I switched to root, probably a month or so ago.
Unless you've got a damn good reason, your administrators are right to withhold root access from you. Your desires aren't good enough.
Search 2010 Gen Con events
I say...Hell no. Not on the main system. That's just asking for way too many security problems. These kinds of things are done for a damn good reason. Now...their own desktops, laptops, some isolated and limited test computer, whatever...that's much less of a problem. But letting users have root access, even limited, to the main system is just asking for trouble.
...and I do NOT WANT ROOT.
I have root on my workstation (cold dead hands and all), but not on a single server--not even a dev server.
sudo on things like mv and chmod gets you a root shell on the box fer chrissakes, why not just put the root password on a sticky on the rack?
When something goes wrong, I don't want to hear, "Maybe the dev did it." I didn't do it--no access. When we go to prod on something, I don't want to hear the admins complaining they don't know how to promote the app because some ass developer did it manually in dev instead of creating a proper install.
If you need root to chmod something, then your admin hasn't set up the box properly. Either he doesn't know what he's doing, or you haven't told him properly what sort of environment you need. Either get a better admin, or write up a clear description of all the functionality you require. Either way, you don't need root.
Of course, the smaller the business, the more likely an admin is a dev and vice versa. In that case, all bets are off.
I have to agree. Prior to my current gig (going on 6 years now) every environment I worked on allowed changes in production. The trouble never ended. People would make changes and bring everybody down. My current job has complete and seperate DEV/TEST/PROD servers. This has saved us a great deal of trouble. There is one other developer that works with me ( in Domino ), and we have complete control to do anything we want to Dev. Test and Prod are off limits for any changes. Even with this I will sometimes install a local server to try stuff that I KNOW will screw the system.
I can accept that I am human. I can accept that I make mistakes sometimes. Anyone that thinks they don't should be kept even farther away from production systems.
Basically you need to have your entire filesystem layout setup properly, with "project" areas where each "project" has its own directory tree with setgid for the project's group on all the main directory and sub directories. Each major "project" would have a group setup for it. Then all file permissions would be covered by anyone in the group, or possibly a "project's lead" who keeps track of all the groups and knows what permissions should be set to different areas (i.e. for data sharing between projects etc.).
Once the infrastructure is in place, the worst thing that happens is that a person is not a member of the "group" and just needs a helpdesk call/form to gain group access ("ok'ed" by a lead member of the "group"). Basically something that can happen in 5-10 minutes time if implemented properly. With the setgid, all new files created in the areas will always be owned by the proper group, which has full access to chmod/chown those files (assuming someone doesn't do "chmod 700") but even then, cron jobs can be setup to run every hour or so that do a "chmod -R 770 /" to any/all project areas (with the cron job removed if you need to lock the area down to no access).
This is how it should be done, no sudo needed. All the work is in the preperation, with true processes needing to be setup and implemented (basically a form/forms for creation of a "new group" (which includes group ownership as well as a box to transfer "ownership" to another person), another form/forms for requesting new data areas (with what group owns the area), and finally a form/forms for adding/removing members to/from the group which gets signed off by the current group owner). Optionally another form for "locking" a data area to keep all access out. Then it simply needs to go to the IT staff which then simply reads down the "process" document and verifies the data in/on the form and either creates a new directory (setting the setgid bit and setting proper group ownership), adds/remove a user to a group, creates a new group, or moves a user to the first name in the group file (for easy tracking of the group owner or updates a seperate documents with this information).
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
Well, a possible solution could be to make a dedicated user writeable dir (/usr/whatever) where these advanced users cound install stuff.
..
...
Sudo is a no-no for me on the other hand for mv/cp and so on, but you can ask for scripts to edit certain files and to change stuff in a dir.
You migh optionally enable a bin dir in the users dir, so a "bin" user group could install stuff there (similar to option 1)
but again your setup might vary by unix (even by linux distribution). It is doable, just molest the admins enough
in unix EVERYTHING is possible imho (yes, yes now all windows admins just flame me)
Part of the reason that "IT Lackey" has a job is because ego-inflated "Software Developer" screws the machine up on a regular basis. "Software Developer" does not get to have admin access to machines that other people use. They get to submit their build to be tested and staged into production.
The real reason that "IT Lackey" has a job is because someone has to know how to admin the system, and the developers certainly don't. They keep the system running, and that means not letting people, like developers, do whatever they please.
I'll tell you a little something about the real world: Most any company that gets a developer with your attitude is a company that's about to put out an ad for a new developer.
I'll give you that you need root to set the date and time, but your system should do that for you with NTP, so it's not that you don't need root for that, but that you shouldn't have to do it...
/bin unless you're the system administrator. If you develop software that can only be run out of a particular directory, please post your name and address in a response to this comment so that those of us who have been forced to use such software in the past can come beat the living snot out of you.
But for your other examples... You do not need root to upgrade your compilers. You do not need to install things in
If you're a developer, you should probably have your own machine, which you would have root access to, but save for setting the time, you don't need root for any of the tasks you've described. Your license to call yourself knowledgeable is hereby revoked.
Even if you do have root, unless you expect the users of your software to have root access as well, you shouldn't be using your root access, or you'll end up wondering why your users have problems that you don't see on your development system.
If the system is truly "PRODUCTION", the users should never ever ever ever ever get root. Root in "QA" and "DEVELOPMENT" environments is something else entirely. I would say not in "QA" environment as that should be a mirror of "PRODUCTION", used solely for testing updates before fragging the "PRODUCTION" environment. In "DEVELOPMENT", the developer monkeys often legitimately need root to work out the issues, change service configs and restart, etc.
By the way... as primarily a network engineer... how many of you out there truly replicate the "PRODUCTION" environment in your "QA" and "DEVELOPMENT" environments... ie: the same model and numbers of firewalls (in HA or Firewall load-balanced config), GLSB's, SLB's, routers (with redundant routing/forwarding engines), IDS's, switches (with redundant routing/forwarding engines and its GLBP/VRRP/HSRP peer), SSL offloaders, etc.. in addition to the web, application, and database servers that all that infrastructure is there for???? I'll bet almost none..... (full replication of a POP architecture is fairly standard in medium to larger ISPs so that a bug, code update etc can be tested/isolated w/o fragging the revenue generating ISP network... the "lab" expense is justified as on-site spares for when the network infrastructure has a meltdown...)
Hell, at time I think I shouldn't even give the users a keyboard and monitor. It's not a question of if the users will screw something up, but when. They are ALWAYS doing things they shouldn't. Thus the less they can do, the better.
The worst are the "I'm a sysadmin" types. For every one I meet that actually has the experience to make them a competent sysadmin, there are 50 that know just enough to be dangerous, but think they know it all.
For example some time ago I decided to roll Firefox out to the educational labs and make it the default browser. All other considerations aside, it's minority status in the browser market makes it far less of a target. Well a couple days later I get some guy in who's bitching about Firefox being installed in "his domain" and he wants it removed. Upon further questioning, it becomes clear he believes that programs are installed in user accounts. I cannot seem to convince him that the program is a local installation on every system and no, I'm not removing it.
Now for Windows systems, the damage someone can do is somewhat limited since all software installs are on the local system. However the UNIX systems all run off a central server. Like hell we are giving anyone anything but read access to that. All the time people want things installed or modified for their particular project. Quite often, they have no idea what they are asking, and what they want done would completely break the app, or worse.
I agree that access should be as limited as allows you to get the job done. Now, in some cases that needs to be total access. Fine, you get a system that's seperate and you assume responsibility for it. If you are doing something such that you need system access, you'd better have the knowledge to fix what you break. In other cases, come to us, that's what we are paid for.
We even operate that way internal to our group. I don't just go and change shit in DNS. Not because I don't know how to, not because I don't have the root password, but because it's not my area. Better I should ask the guy who is supposed to do it. That way, there's less chance somerthing that gets broken.
I think the problem is that some users have a real inflated sense of self importance and entitlement. They think that their project is real, real important, more important than everyone else's. Thus they don't have the time to wait to have the admins do things, they want to just be able to do them themselves. If it messes something up, well then the amdins can fix it. Of course people like that are also the most likely to do something that will break things for others.
The more shared the resource, the more you have to be strict with the access. Even on user desktops, limited access needs to be the rule. Support can't spend hours and hours fixing problems caused by users that don't know what they are doing. It's just not cost effective.
If you truly have the need and knowledge to run your own system, then fine, take it up with management. However part of that understanding has to be you can't bother the support team if you hose things. If you aren't good enough to admin the thing yourself, you probably ought not have admin permissions.
If programs would be read like poetry, most programmers would be Vogons.
I have to agree. I'm neither an administrator nor a developer. I use Solaris and Linux platforms for electrical simulations. Neither I nor my fellow engineers have, want, or need root access. Our admins handle all of the software installations and other system maintenance, as they should. The admins have created groups for the various functions that we perform - the appropriate user is a member of the appropriate group(s). That way the only files that we can mess up are the files that we own. And, fortunately, our admins have implemented an effective backup plan so that when we do make a mistake (and, believe me, we do make mistakes), it can be fixed with minimal headaches for all concerned.
In our case, there's really no way to allow root access to local machines - everything is on the network via NFS. Software installations are tightly controlled and it's virtually impossible for a hardware casualty to cause any significant loss of data.
This is in an organization with roughly 5000 engineers using the *NIX network and an IT budget in the tens of millions of dollars. Believe me, the *NIX side of the house works a hell of a lot better than the Windows side.
Oh, and on my SunBlade at home, I almost cringe every time I run a command as root...
-h-
It's possible to be a good developer yet not be competent to admin one's own machine. In the most obvious case, the code you write is targeted to a different platform. Less obvious, but no less real, are the guys with physics, math, or other non-CS backgrounds who handle algorithms and performance issues on many software projects. Much of that work is platform-neutral, and you can even know a hell of a lot about your target OS (paging algorithms, scheduling algorithms, etc.) and your target physical platform (disk performance, cache sizes, etc.) without having a clue about package management or security.
Your post makes a lot of sense. I'm going to go out on a limb, though, and bet that the folks you're referring to who are competent developers who can't administer their own machines don't refer to themselves as god-like Software Developers ...
Install Gentoo NSA SElinux and whip up a policy to cover these pesky guys.
After a month or two worth of feedback, the system should stablize to the point of giving it to the researcher what they want in an extremely restrictive manner.
The time invested results in a secured system that behaves exactly as your policy dictacts AND still be giving out 'ROOT' liberally.
In their world "god-like software developer" is an oxymoron, because the software developers are peons too. They math whizzes are known to make comments like, "I don't know how you guys have room in your heads for trivial luxuries like XML and multiple inheritance. I don't even have room for basic stuff -- just yesterday I had to pull out one of my old textbooks to refresh myself on simulated annealing."
:-(
But they're right. Developers, including myself, have a tendency to spend time learning admin skills, while ignoring powerful stuff that would actually make us better programmers
Just logging the sudo commands isn't going to give you nearly the auditing ability I suspect you're looking for, and giving them any kind of root-level access to the filesystem is game over.
Figure that any chmod u+s is suspicious and will get caught?
Figure you'd notice their subsequent use of whatever new sudo permissions they just gave themselves?
And, look at that, suddenly their UID is 0.
The list goes on...
People who take a selfish view instead of a system view shouldn't be allowed to muck about with multi-user environments without strict guidelines that consider the system view. Unfortunately this can often come over as a power trip and office politics even when you can bring up valid reasons. Ultimately, if you aren't going to be in the office after hours to fix a production system then you are not responsible enough to have the root password for it - a microcosm of with power comes responsibility.
In the traditional Unix model there isn't as much to worry about: "Make sure you can't get to root from joe user" is most of the problem. We can't get that right but at least it's just one account, oops, I mean "role", to worry about.
So let's make it more complicated. Instead of 1 role let's have 12: user admins, backup admins, repair admins, each with enough oomph to do some real damage, some with enough oomph to ratchet themselves up to effectively being the near-equivelent of root.
I'm not saying the "role" approach and ACL's and the rest are the wrong way to go. I am saying they are tools to be used with care. There is a real cost of overhead in keeping track of all the cross dependencies and cross exploits...and that overhead can increase combinatorically.
Personally I think of them like softlinks: Overuse softlinks and you have a speghetti filesystem. Overuse roles and ACLs and you have speghetti security.
Use them right (and you can use them right in VMS, Solaris 10, SeLinux, etc.) and they can be your friends. Your high-maintenance friends, but friends.
Good practice is to allow users to do everything with their own files under their own UID/GIDs. The main restrictions are that you don't let users do a chmod u+s or a chown. If you want these, or if you want stuff installed on systems directories, you have to call the sysadmin.
I have been a developers for over 10 years now and have happily used the services of the sysadmins. Sysadmins also appreciate to receive requests that are technically OK and that are written respectfully.
I have seen many juniors struggling with the concept of trusting sysadmins. After a couple of questions I usually find an easy way for them to do their work without being bothered too much by these restrictions.
The systems I develop nowadays I prepare under a mortal user ID and package these. The package installation (in system directories) and the running of the software under a technical UID or under root -you should limit root execution- all fall into a clear development cycle (development, integration, production.) To be a software developer means submitting to certain procedures which make you less indispensable and therefore your organization more stable. If you're not prepared to work this way you'll never be a pro.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
As both the primary web developer and web admin, I probably qualify as a "special case" because I'm both end user and quasi-sysadm. The sysadms take care of the O/S, standard software, primary user accounts, etc., and I handle server software configs, user support on the development system, etc. I do have sudo privs for chmod, chgrp, chown, and so forth to give users ownership of their stuff, as well necessary sudo privs to manage certain daemons. However, end users do not touch my production box, and have zero special privs on my development box. My "regular user" log-in has no sudo privs - I'm a Jane Schmuck just like the rest of them.
Good point. And a good sysadmin with sufficient control over policy can limit user privileges with groups. Why isn't anyone mentioning groups here? It's my experience that few sysadmins use groups to partion user privileges very effectively.
I do like programming things that work super quickly, especially when they work super quickly, super quickly.
What's the point in hiring someone to develop software if they are going to spend half a day messing around troubleshooting their system - that's not their job. Policy in most companies is not decided by employees mothers.
Besides, a developer isn't guaranteed to be the best person to fix a problem in the same way that a poet isn't automatically the best choice to write a dictionary.
-- Using the preview button since 2005
A decent amount of people start out with *nix at home, and do everything as root so they don't have to figure out permissions. When they leave that environment for an org's production environment, they think they need root. I did that, too, until I blew away a bunch of mail by accident at my first sysadmin job. Doh.
The only time I've ever considered allowing sudo chown was when I had a bunch of developers working on the same code base and files kept getting added and moved around between dev and QA which no one else could access. I ended up going with a workaround to avoid it.
You get stuff like the guy who has the root password for the purpose of redundancy
This is a good policy, but i read a book at sugested giving it to the boss in a sealed envelope. That way if you die, the system is not locked forever but the boss cant mess with it, and if somebody does he can prove he did not.
Freedom or George Bush
I have worked both as an admin and a developer, and I can tewll you the real answer to this problem, and it does not involve giving out root.
The whole reason people get pissed at admins and want to do it themselves, is that they always feel the time crunch. They have project X that is due on Friday, they submit a request to have something done to the server Wednesday morning, and it still is not done by Wednesday afternoon. This is not always the admin's fault, they have priorities too, and sometimes it is hard to juggle all the requests because he doesn't really know what the real priorities are in terms of the company as a whole.
The solution is to implement a trouble ticket system for all admin requests, and give managers access to it as well, allowing them (and only them) to adjust priorities of requests. That way, managers can set the priorities of the requests to the admin as they see fit. As well, because the managers all know that the developer *did* make the request, and there is a record of it, the developer feels less worried about delays coming from the admin department (passes the buck), and less pissed off at the admins.
The beauty of it is it also takes some responsibilities off the admin, and gives it to the managers, where it should be anyway.
Hell no!
As a so-called IT Lackey I take offense to this (as much as one can to an Anonymous Coward post anyway).
I tell VPs and CEOs "No" often, I had a Director ask me for an Thinkpad because he didn't like Dells, once again my answer was no.
My job, IMNSHO, is to keep my systems running, not fix yours after you break it doing a science experiement.
For example (yeah it's Windows but the principle applies):
You find Article blah blah in PC World, that says how to speed some app up with a few reg tweaks. You screw up. You reset Windows multiple times nuking the known good copy of the registry which you didn't bother to backup before making any changes. You then walk to my office and DEMAND that I make your system work again after you explain all of this to me. You then get really irate as I look at you as if you're George W trying to explain how changing the OSI model will keep up safe from terrorists. You then get really pissed as I hand you a system restore CD and about 20 CDs with various apps on them and explain that since YOU broke, doing something YOU shouldn't be doing, YOU get to fix it. I've already IM'ed your boss with the scenario and what I said before you make it to his office to complain and so your complaint falls on deaf ears and tells you to get started with the installs.
Now the interesting part is yeah I probably could fix it, I do have the toys, a few neat custom ones that can put most any crap registry back together, and fix perms at the same time but my attitude is that if you want to play sysadmin you get to handle what happens when an experiment goes wrong.
No, I'm not BOFH. In fact I tend to cater to my user whims a little too much. "I want a hardened stage 1 gentoo install on this obscure sun workstation, but I need it quickly can you distcc it?"
It's just that over the years if it's one thing I've learned it's this: Know your role; excel at it to god-like levels, but never let someone else think they can do it.
You're a dev. Great. May the heavens bless you and yours with platinum buckets of Cristal. May spring nymphs sing your name in the morning mist. May weeping widows be soothed by your visage. But understand this.
It's not 1980 anymore.
It's not possible to be an expert in everything computer related. I don't care HOW good you are, and if you can with a shiny new TCPIP stack. It doesn't mean you can properly deploy it. Just because you can stitch together five different languages to send an email (actually aside from being pretty stupid that'd be sort of interesting to see) doesn't mean you can setup sendmail to actually make sure it went somewhere. Or the MX record in bind on the other end to make sure it got there.
My CEO is a CEO he doesn't have the training, the time, nor the inclination to do what I do.
My CFO is a CFO he doesn't have the training, the time, nor the inclination to do what I do.
I work really hard, I work at 2 in the morning, not because that's when I'm most creative, but simply beecause I have to. I respond to pages while driving to go boarding with my wife not for the $100k+ I make (yeah right!), but simply because I have to.
It's my job.
"Chinese Amazons, power armor, laser swords.... things just meant to be." - Shampoo, A Very Scary Bet
OK, I'll bite.
My developers need to do things like these on their dev boxes:
* test new mod_alias rules for complex redirects we do
* create new accounts to experiment with privilege separation between the various processes that live behind our site
* Open ports in the default-deny iptables policy I have everywhere, so that other dev boxes can connect to the services they're developing.
* Change the display settings on their box when they haul it into a conference room to use with a projector
Giving them root lets them do these things easily. Conceivably I could write some crazy sudo scripts to accomplish these things, but I think it'd be a complete waste of time.
Mind you, this is for developer test boxes, and their personal desktops. When I give them root (Actually, just wide-open sudo), I give them an SLA: You get root, I get to ditch any responsibility for what you do to your box, other than reimaging it if you blow it up. I'd estimate when I do this that they screw one up once per ten sudo-enabled-machine-years. IE, if I have 100 boxes, I'll get to reimage ten of them per year. So, my choices for adminning 100 boxes are: a) spend a long time writing some narrowly-scoped sudo scripts to do these tasks, and explain to each person how to use them, and have to keep doing it every time they want to do something new or b) Less than once a month on average, log into the admin console (dev servers) or walk over to their desk (developer desktops), power cycle it, and type a one-line command at the PXE boot prompt to reimage it, and walk away in less than 60 seconds.
I'd rather give people root on boxes than have them try to cheat the system. They have physical access to their desktops. If they *really* want root to do something bad, they can get it anyway. I prefer to give it to them, and have them just ask me to reimage the box, rather than try to lie to me and pretend like they don't know why it suddenly doesn't boot, and leave me wondering why.
To be clear, this is for people's own dev boxes. I have an entirely set of policies for my internal servers (eg, my mail servers, DNS servers, LDAP servers, etc - users don't get login accounts, let alone root - only IT can log in), and for the production servers that run our site (they have a complex management scheme that's beyond the scope of this post).
So, giving people root on their own boxes has been very successful for me. You say my way is the wrong way, but I don't see a "right" way to set up their environment that wouldn't waste tons of both my time and the users' time, and even still I don't see what the benefit would be. Can you elaborate on what you think the "right" way is?
On a production box, the admins have access to sudo, and root itself is locked down except for scheduled maintenance/upgrades or emergencies. No paperwork, no root.
As a developer with over 15 years *nix experience, I have never had root access to a box unless I was doing an install, except for my own desktop workstation. In the case of my desktop, the only reason developers had root was so we could kill rogue services during debug sessions gone bad.
Under no circumstances do I agree with any user installing additional software on a box. If it's needed, it gets approved and installed for everyone who needs the functionality, not by rogue users.
I do not fail; I succeed at finding out what does not work.
Similarly, giving a Unix user the ability to execute mv or chmod (or quite a variety of other single commands) as root is functionally equivalent to giving that user full root access.
Even if all the authorized users can be trusted not to abuse the power, can anyone be sure they will protect their password (or other access token) so well that no intruder will ever use their account? I think not.
"But all your emitter and collector are belong to me!"
If you can chmod or cp as root, you can do anything else as root seconds later.
We only give somebody root ability to do something if it's essential to their job, and a team reviews any new application of that to ensure it doesn't facilitate unwanted privilege escalation.
Their basic access to a system at all is reviewed quarterly by their manager, and if he doesn't take action to change the default answer to "yes, they still need this access", they get deleted.
Show me a publicly-traded company that's not acting like that, and I'll show you the next Enron.
I think you're going to end up giving the apache user on your production server sudo access to do "anything" to make that work though.
If something I said can be interpreted two ways, and one of the ways makes you sad or angry, I meant the other one.