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'?"
You are going to get a bunch of responses. most of them from people that will say something like.. "NO." "NOBODY GETS ROOT, PERIOD".
Well, in an ideal world, it would be that way. We would setup systems for people to use and they could just use them without root privledge. Unfortunatley we know that isn't possible if you want your users to actually be productive and get things done.
I work for a large software company. Trust me you'd know the name of it if I could tell you. We use linux on the desktop, as well as the servers. We also have some Microsoft servers that are either for legacy purposes (havent been updated yet) or for testing applications against MS environments. Anyway...
All my users have laptops with Linux on it. They all have the root password to their individual laptops. Many of the also have a server at their desk for their own testing purposes. They have root to that.
However, the "real" servers that are accessed by someone that isn't themselves, the users do not get the root password, ever.
I look at it this way. If you bomb your laptop or your test server, either you can fix it, or you can call me and I'll walk you through fixing it, fix it, or just give you a new clean configuration.
If you bomb my server, I'm going to make sure you never have access to anything, ever.
Don't Tread on Me
Suns also lack, as a default configuration, literally dozens of extremely useful tools that power users expect. That starts with a decent compiler built into the OS, (although I understand they're finally including gcc), standard X libraries and development libraries (because Sun's environment has always been way off the beaten path and need hundreds of man-hours to beat into shape with each new release at least up through Solaris 2.8), tend to be very short on RAM for the same amount of money, have a version of "tar" that inconsiderately makes it incredible painful to do a "ssh root@hostname tar cf - /etc/passwd | tar xf - -C /tmp" and yet have it overwrite your local /etc/passwd because it doesn't strip the leading slashes, have one of the strangest versions of LDAP I've ever seen, and their pkg package management system needs to be....
Well, I'm going to avoid using that kind of language on a bulletin board, but it's not good. But the amount of work necessary to weld together a cluster of 100 Suns into a large and flexible working unit with whatever software the users need to do their jobs is easily enough to pay for another 50 servers. The money saved by buying something other than Suns will buy the backup and cooling systems needed for the whole setup.
There are some interesting 'privledge escalation' things that can happen on machines 'owned' by the user on a big network, though.
The one I experienced firsthand was a Windows NT machine that was my desktop that I ('naturally') had full admin access to. This was a machine on a large corporate network that was very diverse (there were Solaris, OS/2 Warp, Netware, and Windows NT servers on the network). I discovered, quite by accident actually, that if I ran the POSIX Interix (now SFU) shell on my NT workstation (something the company had bought for me, and I had installed myself,) that I could create any account I wanted on my local machine, and it would allow me, using that account name, to access shares on the network, doing whatever I wanted to files my username 'owned'. I am talking about the network that a company that makes implantable medical devices kept their work on. I suspect the 'defect' had something to do with NIS and 'travelling profiles' in Solaris, and the security system not being equipped to deal with other Unix-like hosts on the network that weren't secured. Incidentally, I didn't discover the problem by 'poking around where I wasn't supposed to be,' I simply noticed I was suddenly able to do things to files I normally had access to without entering my UNIX password as required in the past. Something clicked in my head, so I created a local account on the NT box that matched an important person's UID on the Unix system... yep, I had all his permissions.
Delete test account. Never touch again. Too scared to mention it to anybody. It's been enough years now that I can even mention it in public. I hope they've secured things a bit better now, because these days there are unsecured Unixy systems all over the place.
resigned
Man, I wish I hadn't posted in this thread, so I could moderate your comment.
You are the only poster so far who seems to have any understanding... Or at least the only one that doesn't let their understanding get clouded by their childish desire to "have root" even if they don't really need it.
With root access comes responsibility... and I don't mean that like the way they use it in a Spider Man comic book. It's not that you need to exercise caution, ethics, and good judgement lest you become evil; If you have root and something goes wrong, you are responsible. Even if you weren't the one that broke it. Root is a blame magnet. Period. End of story. Unless they're paying you the sysadmin's salary too, you should not want to have root access on any shared system.
Also, people who can't grasp the concept that sudo access to chmod is exactly the same thing as complete root access should have their *nix geek license revoked.
Unless you need to set the clock, signal a process you don't own, or listen on a well-known port numbered 1024 or lower (if it's not a well-known port, you don't need to use a low number. I don't care how much you insist. You don't have a good reason. I'm not listening anymore...), you do not need to be root. Yes, you can do every single other thing you need to do as a user without root. It's not even inconvienient. One must wonder how these people would have survived before PCs...
I have a somewhat balanced view of this, as I work for a University and have a variety of different interactions with Solaris and Linux. What follows is a few notes on Linux vs. Solaris and Access Rights across different categories of system
Firstly, our Production MIS Systems:
Nextly, our Development MIS Systems
Thirdly, Academic Development Systems
Read a few "Ask Slashdot" questions, and you'll understand. Ask Slashdot can almost always be summed up: I'm old and cynical, and longer surprised by clueless fanboys with an exaggerated opinion of their own experience, intelligence, and skill.
I will never understand, however, how any of them manage to find jobs.
On the rare occasions I am not overruled by marketting I tend to prefer the following development setup.
The developers personal machine. Full access, do what you wish, if you cannot trust your people with that then do not employ them. No developer worth his salt will ruin a desktop machine. Someone who either on purpose or by accident comprimeses his machine should be fired. Almost every developer has his own preferences and methods of working, I see no reason to restrict them on their own machine. Want to test a replacement for apache? Go right ahead.
The test server is the step where the locally developed code/setups etc are being tested. Access to this machine is limited by protocol. Basically any chance will have to be documented and be reasoned(?). So a chance would have to accompenied by who did it, why they did, on whose authority and exactly what was done. The test server is NOT a development enviroment, it is a proving ground for new developments. This is sometimes very hard to explain. So in caps, "YOU DO NOT DEVELOP ON THE TEST SERVER, YOU TESTIF the test server works as expected with the new chance then this will be ported to the live server. Friday afternoon is a bad time for this but somehow always seems to be the time desired by the guys who sign the paychecks.
But in principle I see no reason to deny any developer root access to any of these machines. What needs to be in place is proper protocol to make sure that people know how to deal with chances (no point in documenting all the chances if people don't read them) and that you have good people who do not mess with machines.
I have been the victim of bad restrictions to often to have any fate in people that create them. I had to personally subvert a production webserver to handle IM traffic because the office network blocked them and our sales support staff needed it. (Case of an outside department being absorbed in the larger organisation) It tooks over 3 months for them to finally get official permission to upgrade the firewall rules. I myself was denied SSH access to the outside webservers for a full week until I told them I would simply work from home permanantly until it was fixed.
If you have good people they can be trusted with root access. If you do not have such people then they cannot be trusted with being let into the building. My first IT job had a guy who installed a keylogger. He didn't have root access, he simply had a limited account on a windows machine and downloaded some exploit kit.
But in the same job I was being outsourced to a very large dutch company and had root access on their AIX production machines. I, a new then new newbie noob had to do my development on the production machines since my desktop was to restricted to install the software needed and in any case couldn't handle the filesizes involved (good luck opening a 2gig database dumb in either word or notepad on NT4.0). One morning I was early (so I could leave early and miss the endless meetings) and was asked by the director of the company to start a database. I was the only person who could do that, if I had not started that database the entire national compnay with a hundred offices could not have started the working day. (Was a temp agency).
A stable production enviroment does not come from limiting your employees, it comes from not letting your unix admin quit in disgust and having proper training in place so your critical servers do not depend on a hired developer who is still reading his Unix for dummy's manual.
If the above sounds fancifull then be glad I did not tell the complete story. It was the most insane enviroment I ever been in. It was so bad that when the company was bought by a rival and they learned about the true state of the accounts it even made the one national newspaper. While it focusses mostly on financial issues it also reported that they found the IT department to be a total mess. Not bad for your first assignment eh?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.