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.
Do you fall under the scope of the Sarbanes-Oxley act? By not allowing sudo or plain 'ol root access, accountability goes way up if you have to call the help-desk to perform whatever action you need to take. You have effectively limited the scope of those who can make changes to the system and presumably the changes that are made are logged.
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.
OK, here's my cynical answer as a UNIX admin: I limit user access because it's one way to keep my position appearing valuable. As long as I'm the guy they have to go to for any system changes, and as long as I can tell the PHB's I'm monitoring their activity, my job sticks around.
All's true that is mistrusted
Can't SELinux achieve this (ie, fine grained security access control within the kernel)?
.... we run a SOA enviroment with about 50 different apps on many machines. We run each app under a seperate uid. App developers are in a group named for the app and members of that group are given full sudo permissions for the app uid. Creative use of /tmp and cp have eliminating most of the chown requests. Only issue is for those few developer's than need to work on more apps the the 32 group limit allows. They have to suffer with the newgrp command.
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.)
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.
,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.
Congrats!
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
Good, Good!
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)?
Hell No!
If no, why don't you?
Because it is my responsibility, and my responsibility alone, to keep those machines running. If you screw up the system, then I will have to work later and possibly come in on the weekend to fix it. This is not something I am willing to risk.
In addition, as an ex-*NIX Administrator, you should know that the best way to keep a secure system is to give the least privs possible.
Can I get an eye poke?
Dog House Forum
If you're at a defense contractor, they're probably following the DoD Guidelines of least privelege, logging, stuff of that nature.
What you're asking is, essentially, to establish yourself as a certain class of user under whatever scheme you're using, or for some kind of "well, Slashdot agrees" circumvention of guidelines.
It reminds me of a time that I was working on such a machine, and I sat in a conference room where people were trying to bargain with me as if I represent the STIG. The simple fact of the matter is, the STIG is a set of guidelines, and nobody's opinion will change the contents of the document.
Stop trying to negotiate it.
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.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
> In short, get me the resources I need to do my job (and none past that), or get the fuck lost.
The system also isn't there so you can play with it. It's there to make the company money, and if your inflated ego gets in the way of that (by screwing around with SOP and putting production work at risk just because you think you're too important for change control, or limited access) then you can get the fuck lost.
No one said anything about not giving you what you need, they just said you don't need root.
If you need something done - ask for it, if there is a lot of things you need done, then there's probably a larger problem to fix.
Check out the 'rootsh' package for a logged/auditable shell meant to be launched from sudo. When launched from sudo, it can provide a full root shell so it might not suit your needs.
At MIT, all Athena workstations have the same root password, which is freely distributed. Any user can get the root password by typing in tellme root at a console. There are thousands of these machines scattered all around campus, with many different hardware configurations. This has been policy for many years now. Sometimes you get stupid kids doing stuff like this, but other than that, it seems to have been working...
if you work for Sun.. Why do you not know the Product name is Trusted Solaris (not secure Solaris.. what is that ) and you should also know that Trusted Solaris is a PL4+ system under DCID 6/3 and you guessed it .. SELINUX has acived PL4 + and TSABI with Net Top II.
No.
Because they will break the system and then they will blame the IT department. Logging lets you know who did it but the blame is still entirely assigned to the IT department.
Developers are even worse because they think they know it all but 9 times out of 10 they know next to nothing about system administration. I would be more willing to give sudo rights to a normal user who follows a documented procedure than I would to a gung-ho know-it-all "hey I run Linux at home gimme full root access" developer. I've seen developers chmod 777 their files because they don't understand permissions. Do you think I'm going to trust them with root access to mv or cp? No chance.
I've seen developers ask for sudo access to run patchadd, to run pkgadd, to run pkgrm, to run vi (how I laughed at that one). They are rejected every single time. If they have a process that needs to run regularly as root then it can go into a script in /usr/local, permissions will be locked down so only root can modify the script, and a limited number of users will be granted access to run that script. That's as good as it will get without divine intervention (aka the CEO).
If the application developers are making changes that require frequent superuser access - especially to commands like chmod and mv and cp - then perhaps they need to rethink what they're doing. It sounds to me like they're doing something wrong.
"Beowulf can mean cheap hardware, Sun doesn't." -- Wrong! Sun X64 servers are the least expensive and the most ideal (branded) boxes for Beowulf type cluster. .. can you say the same for Linux ? .. and in my opinion, you're looking at it from a loosing vendor's point of view, talking about what's bad in this solution." -- It is clear the topic poster hadn't done his homework before suggesting the migration. This itself is enough evidence to point out the suggestion is questionable. .. And as the parent poster mentioned, if you are running MPI jobs, you do not need to be a root user. .. And yes, I build supercomputers for a living.
"Trusted/Secure Solaris adds huge amount of overheads to installing and configuring and using a system that they just might not need." -- Wrong again. Trusted Solaris is or for that matter securing any Unix like OS is about similar effort. Now the difference is with Solaris, you have a vendor (ie Sun) willing to put their money where their mouth is
That said, If as an administrator (presumably) you think securing your boxes is too much work, you ought not to be an administrator to begin with.
"In my opinion you have forced your customer to make a move on questionable grounds
That said again, have you looked into Solaris 10 RBAC ? (Role Based Access Control)
If cost of concern and hence the need for Beowulf type cluster, the user might as well go about with Solaris 10 beowulf cluster with Sun MPI-2 stack and Sun Compiler (available for free), which I would think would be a lot less painful than moving to Linux and mucking around for a few months to get the cluster up and running
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.
i am not a programmer, but isn't that problem solved by tools like CVS and SVN?
Snowden and Manning are heroes.
ftp://ftp.funet.fi/pub/local/src/omi-file.tar.gz
It allows users to grab ownership[1] of files in certain per-user configured paths, whenever they need to (sample config file included). This allowed us to manage the incoming ftp directories without going insanse.
It was written some 15 years ago by Matti Aarnio.
[1] Ownership is "omistus" in Finnish, hence the name of the tool
Trusted Computing FAQ | Free Dawit Isaak!
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.
Speaking as a systems admin for compute services and one of two who looks after HPC equipment at the university i work at I'd say the following.
Why would you move the modelers to Linux from Solaris? There is no real advantage....
Moving compute work away from the Solaris/SPARC combination for us isn't only an advantage from a cost perspective it's also an advantage for compute capability and most of all what users require. One of the big applications used by the scientists I look after shared compute resources for is matlab. As for R14 (v7) matlab only supports Linux/x86_64 for 64bit computing so if you want to do analysis that uses more than 4gb of ram you're limited to either Linux/Opteron or Linux/Intel w/EM64T. Incidentally we're running on a V40z which while it's a fairly impressive peice of harddware does have some annoying things about it. One that springs to mind is the LOM card is absolute rubbish,
Sure a Beowulf cluster is a nice piece of hardware, but hardware can only compensate a bit for programmer productivity...
I'd mention that we don't use beowulf clustering within mid-range compute. On the HPC platform we do have an SGI Altix which gives us one major advantage over virtually any other system, a single system image. With our current system we're able to address 64GB of ram from anyone of the 32 processors in the system. Clusters really don't have this capability without taking major performance hits when MPI/etc tries to reach out accross the interconnect to remote memory. the ccNUMALink running at 20-40Gbit/sec has some massive advantages. It's also worth noting that the 32P Altix cost 100k less than a 8P SunFire 6800. Not to mention the massive performance advantages that Itanium2 processors have. While most will go "eh?" to that statement we've found that I2's chew through large datasets like soft butter. The speed of these processors can be hard to realise at times due to a lot of optimisation occouring at the compiler level or through the adition of the Intel math library kernel modules.
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.
This may not be true for all areas but for us moving from Solaris to Linux wasn't that big an issue compiler wise. Most of the users were already using GCC on the Sun systems because the Sun Forte (SUNWspro) compiler was unable to deal with the majority of the code that was being developed by their peers in other universities or due to issues linking to external libraries for applications such as netcdf/hdf/grads/etc. A large proportion of code these days is written by users on the cheepest possable platform which is generally a x86 system running linux and that's what the code is tested on. Few have access to Sun/SGI/IBM/SuperDome style equipment as development machines so the big users end up either having to rewrite large chunks of the libraries or their code or simply move to the more commonly accepted compiler and toolchain.
You mention Trusted Solaris many times. Trusted Solaris doesn't ship with hardware as standard and many systems shipping today with Solaris 10 which does have a large majority of the Trusted featureset in it is being removed and replaced with Solaris 9. 10 isn't accepted within the VAR community yet as a "supported platform" for the wide range of applications being run by scientists or even for more mainstream corporate applications. While we do run some systems with S10 it's been for specific features such as zones so we could run multiple squid processes on a single hardware platform.
For the original article. In the environment of a shared compute facility there should be no reason for a user needing root access to a machine. If they are wanting an application installed for mulitple users to access then they should be handing the app to the administration team to install and maintain. One thing that does annoy me within my environment is that the suppor