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'?"
Much as I hate to break it to you - this is SoP.
End users Do. Not. Get. Root. Even allowing SUDO access to change file permissions, copy, or even move files is just asking for trouble.
Installing software or libraries? Hell no. Not on a live system.
If they have a development-type machine at there desk, that's one thing (just don't call for support if you break the damned thing). Even then, my preference is that they have limited access.
On large, shared systems, users get as much, and as little, access to do their jobs as necessary, and absolutely no more than that. I have to keep the system up for other users, I can't have power-user #1 screwing things up by changing permissions on something they really shouldn't be touching (let's take the compiler for example...)
A little knowledge makes one dangerous, and I'd just as soon noone other than those paid to admin the machines have access.
And even allowing chmod, mv, etc via sudo can be dangerous. Someone accidentally issuing a "sudo chmod 777 -R / ", having meant to type "./" for everything below their current directory, isn't going to be good for your system health and is going to be somewhat of a pain to recover from, even if you do know who screwed things up.
Developers with Linux experience are a LOT more dangerous than developers without linux experience. My experience has been (100% of the time) when I give "experienced developers" access to commands like 'chmod', I find all kinds of files mode 777 (among a list of about 10,000 random, stupid things developers do) because, well, I've heard pretty much every excuse you can imagine.
The problem is that as soon as people outside of the core sysadmin team have access to critical system commands (cp, chown, chmod) the integrity of the box is left to chance. There's always the possibility someone is going to do something outside the policy. Sysadmins make it their job to know and understand the impact of every change to a box. Developers tend to make changes in order to get their stuff to work, regardless of the consequence (hey, each group is just trying to do their job, which is "make it work!!" -- I'm not defending either side).
My rule of thumb:
- Developers get root in their dev environments.
- Sysadmins get root in the production environments (developers shouldn't even have user-level logins to these machines.) If your company is releasing software (even for internal use) properly, the IT group will be managing the code as a product, using developers as a help desk rather than letting them manage the applications directly.
Stick to this and everyone will be happy.
-- People who hate Windows use Linux. People who love UNIX use BSD.
This sounds to me kind of like the situation in a university Unix network. I'm not entirely sure I understand what you necessarily need that wouldn't be available (though I would like to know, to get a better understanding of the question). Certainly, at the university I attended, we didn't have sudo access, but we were able to develop some rather powerful applications.
/usr/local/whatever, and tell them how to set up their LD_LIBRARY_PATH to link against it, and they're good to go.
I can see an adjustment period of a couple of months, where applications you regularly use aren't available, so you ask for them to be installed. After that, assuming they don't see the general need for an application (or they don't want to have to officially support it), you could theoretically install applications under your home directory. (I was thrilled when I became a grad student, and got 100MB of disk quota, so I could compile and run Blackbox as my window manager instead of the crappy twm we were generally stuck with. In fact, I made it globally executable, so my friends could use it as their window manager. In fact, I received a phonecall once from one of the admins, asking me what this spinning "blackbox" process was running on one of undergrad servers, since I was the only grad student or professor (and therefore in the phone directory) who also ran it.)
These days, as part of my regular job, I am one of the unofficial sysadmins of a Beowulf cluster (largely because I'm the one of the only ones who have developed MPI applications that run on it). I get the odd request from other users who want me to hook them up with some library or such. I compile and install it under
Again, I have to ask what you need that requires root or sudo access, that can't be solved by the rare admin call or installing under $HOME. (I really don't mean this in an insulting way. I do want to know. The story post is a little brief.)
Another sysadmin who is going to tell you that I don't give out root or sudo access to users. Most users who think they know enough, or even DO know enough, really know enough to make big problems. They invariably never check with me before making a change, or tell me that they made a change, or even admit to having made a change when they inevitably screw something up.
I make them come to me for everything. But not directly. That's what the ticketing system is for. The ticketing system justifies my existence, keeps any requests from slipping through the cracks, and helps to keep track of ad-hoc changes made to any given system.
Many times end users think they need root for something when they don't. For example, there might be some niche tool that they need installed on a system. Or do they? If the one user is the only one that is going to use it, I advise him to do something like "./configure --prefix=~" to build apps to install in his home directory. You don't need root to install apps anymore. Besides, if you want an app installed for everyone to have access to, sysadmin should be doing that anyway.
It might be a pain in the ass to make you go to the sysadmin for everything, but in the long run it will keep things running smoothly and perhaps force you to be a little more disciplined in your work.
I don't really get the original premise. Nobody needs to be root to run chmod, cp, mv, etc on their own files. The only command mentioned one might need root for is chown. Which would make me ask the question, why do you need to change file ownerships so often?
It would take a hard-core serious business case to convince me to grant someone root access, even sudo-limited root access to a production system. The fact that I might have a "log" of whatever broken thing they did to take a business critical machine down is fairly irrelevant to me. My job is to make sure that doesn't happen in the first place.
Nah, that's just a standard limitation of NFS. There is no security in NFS; the unofficial expansion of the acronym is No Fucking Security. The server trusts the client is providing a valid userid. You spoofed the userid and NFS has no way to detect that because the server assumes the client always tells the truth.
Some environments implement netgroups to limit the opportunity for attack. The server checks incoming client connections against this list; clients on the list are assumed to be properly secured so nobody using the machine can spoof a userid. This is not very effective either because spoofing a client IP address is almost as trivial as spoofing a userid.
What you found was simply standard practise for NFS, as frightening as that might be.
To address the article's question, groups solve more than just file permissions; consider an environment in which users in the admin group have the ability to do things (via sudo) as the admin user, who owns /usr/local and all of its children. This lets priviledged users install things, but prevents them from accidentally messing with them (the admin group should not have write access to /usr/local, so sudo is required).
A more restricted implementation would chown /usr/local/stow to the admin user and grant the admin group sudo access as the admin user plus sudo access to the stow command (or perhaps a shell script that ensures items are stowed to /usr/local).
Of course, /usr/local is only one potential target. Perhaps your environment is better suited for /arch/beta or /opt. Also note that this idea is easily abstracted and applicable to other tasks.
Use my userscript to add story images to Slashdot. There's no going back.