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'?"

Comments

SUDO Commands

[Traxton1]

You forgot AIII-YAAA!

Re:SUDO Commands

[mrbooze]

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.

Re:SUDO Commands

[CapnGrunge]

Wait until he shows you his mad kung foo skillz.

Re:SUDO Commands

[dsoltesz]

I used to be both sysadm and web admin of my web server. When I moved to a different division where there is a sysadm group, I thought I'd die without root. Not only have I discovered I don't miss it (given I have some sudo privs), but I quickly learned I didn't miss sysadmining my own server - I get the great joy of focusing on being a web developer and leaving most of the fuss to someone else.

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.

Re:SUDO Commands

[TallMatthew]

I used to be both sysadm and web admin of my web server. When I moved to a different division where there is a sysadm group, I thought I'd die without root.

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.

Re:SUDO Commands

[Lehk228]

i am not a programmer, but isn't that problem solved by tools like CVS and SVN?

Re:SUDO Commands

[TallMatthew]

Yep.

IIRC, there were config files, properties files and the like that needed to be modified within QA, who received a "push" of the codebase rather than checking it out. Too, the web developers weren't putting their stuff in CVS.

Re:SUDO Commands

[level_headed_midwest]

Most people I know that have a UNIX-like box run Linux. In almost all distributions, the user runs as an unprivileged user but has sudo rights. I happen to be in this case and never have to do anything that requires real root access. I bet most people have a similar case too.

Re:SUDO Commands

[Anonymous Coward]

Sounds like your organization needed to better enforce QA policy on its development team rather than give admins a hard time.

Re:SUDO Commands

[cayenne8]

I do/have done work at a gov/DoD contractor...usually as a DBA. The SysAdmins are contractors too. I find it very easy to work with them. They give me sudo access to do things I need to do (on some Oracle boxes, we run the Apache server too)...but, it is a give and take thing. They know us enough to trust us to know what NOT to do. If I have a question..I always ask first.

If I need something I don't have access too...I email them...they review it and usually is not a problem at all getting access we need to do our jobs. It just requires everyone not to be so adverserial, and each person knowing how to do his job.

Now...this is on the Sun boxes. On the windows boxes, when running at the oracle user...we have to have them babysit us...apparently the DoD rules won't let them give us the access we need on MS boxes...so, they have to log us in...and sit with us till we do our upgrades/patches. This is a major PITA....and one reason we're always pushing for the databases, at least NOT to be on win boxes.

Re:SUDO Commands

[cloudmaster]

Man if only there was a way to make directories setgid, change the default umask to 002, and put the developers in the same group. ;) It gets even easier when using samba / ftp / something else, when you can make the file transport force permissions...

To further explain that, when you enable the setgid bit on a directory, newly created files will inherit the directory's group, and newly created directorys will do that as well as inheriting the setgid bit. You then set the users default umask to either 002 or 007. You also have to create a unique group for each user, then, and set that as their default group so they're not accidentally creating files that are group writeable. You still make everyone a member of the users group, though, and tell the users that they need to manually change the group any files that they want to share. It works well for typical situations.

To initially set that up:

cd /path/to/development/files
find . -type d -exec chmod 2775 '{}' \;
find . -not -type d -exec chmod g=u '{}' \;
chgrp -R devgroup .

Alternatively, do all that with one obscene find commandline so you only recurse the tree once, and later on have no idea what the heck you typed:

find /path/to/development/files -exec chgrp devgroup '{}' \; -type d -exec chmod 2775 '{}' \; -or -exec chmod g=u '{}' \;

Re:SUDO Commands

[TallMatthew]

To further explain that, when you enable the setgid bit on a directory, newly created files will inherit the directory's group, and newly created directorys will do that as well as inheriting the setgid bit.

Is that the sticky bit? You'd think after having being asked that question during a few dozen clue checks I would know by now, but I remain a clod.

I can tell you the difference between RIP and OSPF in my sleep, though.

Re:SUDO Commands

[chrisj00m]

Is that the sticky bit?

Not quite. setuid/setgid, when applied to a directory, make files created within that directory inherit the user/group of the directory, instead of the user/default group of their creator. the setuid bit generally doesn't work on directories (for rather obvious security reasons), unless a particular flag is set against the file system in /etc/fstab.

The sticky bit is used to secure directories like /tmp, and prevents you from removing files from the directory -- even if you have write permissions -- unless you are the owner of the file.

Re:SUDO Commands

[cloudmaster]

To expand on the other reply, you're familiar with permissions, right? You have the user bits, the group bits, and the "other" bits, given as three octal numbers consisting of a read, write, and execute bit (in that order) - so mode 754 would be 111 101 100 in binary, with the "set" bits meaning user having read, write, execute, the group having read and execute, and the "other" having just read. Well, there's an implied 0 at the beginning of the 754 you might type - it's really 0754. There are three more less used bits at the front. In order, they're setuid, setgid, and "sticky". They do slightly different things on directories than they do on files, and the effects are well documented in the chmod man page as well as all over the internet if you're unfamiliar with them. :)

Hell no

[Anonymous Coward]

Because if you allow someone chmod permissions, for example, all they need to do is something like "chmod 777 /etc" and you're system security is screwed.

Re:Hell no

[Anonymous Coward]

No, not if you set it up properly.

Re:Hell no

[Anonymous Coward]

That is providing they are in the "Wheel Group". Are you giving priv access to a group?

Re:Hell no

[Anonymous Coward]

Wouldn't you really need to do a chmod -R 777 /etc to be effective?

Re:Hell no

[Hegh]

Can't chmod /etc without being root anyway, since it's owned by root:root. I think chmod is safe, it's just chown that is worrysome.

I've had a few minor difficulties with that; from what I can tell, the only reason chown is not generally available to normal users is the chance that someone could chown a file in his own home directory to somebody else and then be unable to touch it and need to get help from the admin to fix it.

Re:Hell no

[Anonymous Coward]

That'd be 'chmod -R 777 /etc' for disasterous consequences, please. Anything
else is a feeble attempt to cause major damange by a person who has precisely
zero clue about Linux, UNIX or the way the internet spins around :)

Re:Hell no

[defMan]

I've had a few minor difficulties with that; from what I can tell, the only reason chown is not generally available to normal users is the chance that someone could chown a file in his own home directory to somebody else and then be unable to touch it and need to get help from the admin to fix it.

Or they give away files to avoid their quota limitations...

Re:Hell no

[Anonymous Coward]

Imagine if you could do the following:
$ cp /bin/sh ~/sh
$ chmod 4755 ~/sh
$ chown root:root ~/sh
$ ~/sh
# ...

Re:Hell no

[Pepi]

The recursion will make it easier to wreak havoc, indeed. Some daemons will refuse working if their config is world writeable, so the change would probably be easily detected. But you don't necessarily need it. Remember, if you have write permissions to the directory, you can swap one file with another (with content of your choice). So if your /etc is world writeable your system's security is compromised, only in a more subtle way.

Re:Hell no

[moro_666]

sudo chmod -R a+rxw / && rm -rf /


what do you mean with the system has left the building ?

Re:Hell no

[PygmySurfer]

Can't chmod /etc without being root anyway, since it's owned by root:root.

But if they have access to "sudo chmod", which is what was suggested, the command IS run as root.

I've had a few minor difficulties with that; from what I can tell, the only reason chown is not generally available to normal users is the chance that someone could chown a file in his own home directory to somebody else and then be unable to touch it and need to get help from the admin to fix it.

chown IS available to normal users, and the scenario you described is certainly doable.

Re:Hell no

[jrockway]

Even better:

Open up two xterms. Run sudo chown root:root /etc/sudoers, but don't type your password at the password prompt. Run sudo chown jrockway /etc/sudoers (in the second xterm), and type your password this time. Now run emacs /etc/sudoers, and add a line like jrockway ALL=(ALL) ALL. chmod 110 /etc/sudoers. Then type your password into that first xterm. /etc/sudoers is now back to having permissions acceptable to sudo, and you've 0wned the system.

(For those of you just tuning in, sudo won't run unless /etc/sudoers is owned by root and has permissions 110. Otherwise you could just do a plan chown and edit.)

Re:Hell no

[fimbulvetr]

chown removes set*id bits.

Don't give them full control

[Architect_sasyr]

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.

Re:Don't give them full control

[slashjunkie]

Can't SELinux achieve this (ie, fine grained security access control within the kernel)?

Re:Don't give them full control

[Architect_sasyr]

Probably can, but I have too much trouble (as in, I don't have the time) re-configuring everything to work around the thing. The modules I can write in my own time, and they are easily updateable. Fighting with the SE just isn't something I'm up for. It probably is easier to use, but when you know something well already...

Users != Root.

[paitre]

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.

Re:Users != Root.

[Anonymous Coward]

"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)."

The reason of existence for you, IT Lackey, is to make sure my machine is working. Then I, god-like Software Developer, can develop the company product which in turn gets sold by the rat-faced vermin in Sales and Marketing.

IT Lackey not giving support => IT Lackey should no longer be employed.

Re:Users != Root.

[Anonymous Coward]

all well and good but I have worked in places where I definitly had more skills than the admin and had to wait long periods of time for the inept admin to fumble their way through somthing I could do in 5 seconds.

Re:Users != Root.

[Anonymous Coward]

note - government contractor. there's probably regulatory/etc. requirements (in order to ensure no backdoor code, etc.; what if Iran offers mucho money to someone to insert code? etc.). your example does not apply.

Re:Users != Root.

[tomhudson]

You're not a developer if you can't even maintain your own machine.

To be a decent developer, you have to understand not just how to write code (or, in too many cases, "move pretty icons on a screen") - you have to understand the environment it runs in, including file permissions.

• You break it - you fix it.
• You malloc it, you free it.

Didn't your mother teach you to clean up after yourself?

IT Lackey not giving support => IT Lackey should no longer be employed.

So-called "god-like Software Developer" can't even maintain his own machine => waste of skin exposed.

Re:Users != Root.

[Frumious Wombat]

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.

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 /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.

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.

Re:Users != Root.

[Anonymous Coward]

I suggest you start reading BOFH and get prepared to have your attitude adjusted someday.

Re:Users != Root.

[Anonymous Coward]

Wow. All I can say to this is 'Wow'. Having worked in IT (programming, support, DBA, etc) for over 10 years, I have never encounterd such a jerk. You can't maintain patches? Good. That's why there is a standard image, a standard machine, and COMPLETE LOCKDOWN. You are a developer? That's what the damned DEV boxes are for. Your desktop is for you to get your precious email, read your stupid sites, and pretend you know what you're doing. No root. Not now, not ever. Even admins don't get to use root except in a carefully audited way, with careful controls. At most you'd get sudo.

If you worked at my company, you'd find yourself on a VT100 so fast it would make your head spin. We don't tolerate attitude like that. Not with an IT of 20 supporting 2000 users and 10 production lines.

Re:Users != Root.

[aaronl]

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.

Re:Users != Root.

[HardCase]

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-

Re:Users != Root.

[Anonymous Coward]

Hey mods, that wasn't flamebait.

Re:Users != Root.

[try_anything]

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.

Re:Users != Root.

[dfjunior]

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 ...

Re:Users != Root.

[try_anything]

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 :-(

Re:Users != Root.

[dbIII]

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.

You get stuff like the guy who has the root password for the purpose of redundancy doing experiments on a couple of subnets to learn about routing and preventing 40 users from being able to do anything other than newspaper crossword puzzles until the problem is found. I had to wait nearly an hour after that one before I was sure that I could talk to the guy in a civil fashion - and he still thought I was an arsehole for asking him not to disrupt things because he didn't know enough to know that it was wrong and he didn't lose connectivity, so I must have been making things up.

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.

Re:Users != Root.

[dsoltesz]

It's one thing for a developer to maintain his own system, but when all the developers work on the same multi-user system, you don't want them all dorkin' around with it. In our environment, sysadms manage the system, there is an area for one delegated developer (and ex-sysadm) to install and manage software for the group - no sudo privs needed. The one delegated package maintainer can coordinate upgrades with others, and because he's also one of the developers, can test and support those packages much more easily than the sysadms. Yes, all the developers would definitely benefit from having their own boxen to beat on, but only a third of them do.

Re:Users != Root.

[thogard]

I've found that with 3 simple changes, I don't need root much at all.
A sudo like kill function or even a suid root program that does 'kill -1 $*'
That means anyone can restart any services but they can also logout anyone on the system and end any well behaved programs. If this tool is given to people who have root access, you will find thier use of su goes way down.
Change port binding rules. This has got to be one of the stupidest things still around in the Unix world. The rules should be you can only open ports 1000. This used to be a 40 byte change to the linux source and gets rid of nearly all suid programs and special root startup scripts in a modern system.
Change chown rules to back the way they used to be in the days before posix when any user could give away their files. There are security issues to this but sudo can limit them.

Re:Users != Root.

[darkonc]

Changing permissions on a file can be done (if it's your file) without being root -- chmod is your friend.
If the file isn't yours, then you shouldn't be changing permissions.
If you want people to be able to give away their own files, I believe that there's a sysctl setting that will allow that for most modern Linux boxes.
If not, then I'd be willing to write a setuid program that allows you to give away ownership of files owned by you (but only if there aren't user disk quotas, because giving away ownership of files is a really nice way of working around quotas and/or just messing around with your workmate's quotas).

Examples of what can go wrong when you allow people to arbitrarily change ownership of any file have already been given. Let's just say I wouldn't allow it either.

Re:Users != Root.

[ComputerizedYoga]

Developers, including myself, have a tendency to spend time learning admin skills, while ignoring powerful stuff that would actually make us better programmers :-(

When I first started as a sysadmin, my devs all had admin access, root on the servers, etc. They spent so much time flailing trying to figure out how to do administrative things they shouldn't have been dealing with that they had trouble doing their jobs.

Now, they don't have root. I keep the systems running and happy and handle the things that they're totally clueless on (or just shouldn't be trusted with) while they write the code and the papers that keep getting us our research grants, and everyone is happy.

Re:Users != Root.

[SmallFurryCreature]

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?

Re:Users != Root.

[MysteriousPreacher]

You're not a developer if you can't even maintain your own machine.

To be a decent developer, you have to understand not just how to write code (or, in too many cases, "move pretty icons on a screen") - you have to understand the environment it runs in, including file permissions.

You break it - you fix it.
You malloc it, you free it.
Didn't your mother teach you to clean up after yourself?

IT Lackey not giving support => IT Lackey should no longer be employed.
So-called "god-like Software Developer" can't even maintain his own machine => waste of skin exposed.

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.

Re:Users != Root.

[Anonymous Coward]

I couldn't agree more... everyone knows that the biggest thing you have worry about in terms of security are your own legitimate users, not some outside hacker getting in. This "ex-*NIX" admin obviously never operated within the confines of an ISP or handled any system with a decent number of users on it - there's that unavoidable level of rascality present in all your users, they will break things out of malice or sheer ignorance. Either way it will happen and reducing super user access is the only way to reduce the damage. Let them mess with their own files but don't give them system access - as stated above this is SoP and the article above is just an unfortunate lament of someone experiencing that loss of administrative power.

Suck it up, if you really were half the admin you claimed to be you would not have written this article.

Re:Users != Root.

[Simon Brooke]

Developers, including myself, have a tendency to spend time learning admin skills, while ignoring powerful stuff that would actually make us better programmers.

Sometimes we have to. I'm not really a disciplined enough person to make a good sysadmin, but we don't have budget to hire one so I have to do it. Still, knowing you're not the right person for the job does have the benefit of making you extra careful.

Re:Users != Root.

[Anonymous Coward]

as a power user i remember having these kind of restrictions on the *NIX we were using at the time early 90'ies . the admin were so control freaks , it was not business it was personallities .So i took me a little time a few years of coding in c++ to rebuild all the numerical calculation off those boxes where those idiots had their hand on . all the calculation were done back on the PC of the users were USERS had all control. i was luky PC powers got so fast we could throw the *NIX boxes with the admin back on the street were control freeks should be doing police work.THAT's how Microsoft won empowering the user to use computer for real work , and not the IT departements who have no clue on the real busines of most of the firms they work for.

Re:Users != Root.

[smittyoneeach]

Give 'em a box and let them virtualize an entire network under, say, VMWare. All of the mad fantasies are explorable, albeit with a performance hit.
Be sure to tell the person that, if it's not their job to be fannying about that way, the hours are to be charged to vacation.
The wallet is a lense capable of impressive focusing of the thoughts...

Re:Users != Root.

[smf]

Interesting how your sig:

"Those who would give up essential Liberty to purchase a little temporary safety deserve neither liberty nor safety."

relates to your message....

Re:Users != Root.

[Anonymous Coward]

"The reason of existence for you, IT Lackey, is to make sure my machine is working."

No, our existence is to make sure everyones machine is working. You are not the most important user by a very, very, very, very long way. If you break your own machine, expect your request to have it fixed end up at the bottom of a very big pile, code monkey.

Re:Users != Root.

[tomjen]

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.

Re:Users != Root.

[tomjen]

There is another interesting problem. I copy a shell to my homedir and set the suid bit, then i use your program to chance the ownership of the file to root.

Re:Users != Root.

[TeraCo]

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.

Well see, that's the problem in itself. Most IT Support staff don't spend half a day fixing their own computers, and if you're doing the right thing you won't have to either.

Re:Users != Root.

[Shadowruni]

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.

Re:Users != Root.

[AtomicBomb]

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

This really hits the point. But, I am from the other camp (ie physics, maths, engineering, or other non-CS background). When dealing with complex simulation code, it is sometime quite frustrated to work with programmer having a CS background. They tend to care about the typical concern of ordinary software, without having a clue about numerical accuracy, the need for verfication/reproducibility of the result etc. So, it should be better to mark the territory clearly: I won't step inside the security/ package management side of the system and please respect our special need in software development.

Re:Users != Root.

[pugugly]

That's nice to know - I keep having to look up stuff I swear I knew in college and thought it was just me.

Pug

Re:Users != Root.

[MysteriousPreacher]

Well see, that's the problem in itself. Most IT Support staff don't spend half a day fixing their own computers, and if you're doing the right thing you won't have to either.

I completely agree if someone is effectively damaging their work equipment then that must be addressed through disciplinary procedures in the same way you'd kick the arse of a delivery man who keeps thrashing the company van.

Re:Users != Root.

[BoneFlower]

I don't use root on my linux system either. Those times I actually need such access, I can easily and quickly su, get done what needs to get done, and exit back to my login shell. I only actually log in as root when I'm doing major work such as compiling the kernel that requires me to be in root for an extended time. And once thats done... I log out and log back into limited. Even the admins of a box, whether its a shared system such as a server or group workstation, or their PC, should only hop into root when necesary, they shouldn't do it just because they can. *nix has facilities to let them do it.

Things like sudo that give limited accounts a "partial root" level of power should only be used when that persons job actually requires such access. And even then, unless the access is required each and every time they log in, they should have a normal account for general use.

I do use admin on windows because it's a pain in the ass to do otherwise. I do need to read up on that though, either set up something between a typical user and admin, or find a third party su equivalent for win32.

Re:Users != Root.

[howlinmonkey]

Windows has something of the equivalent of su. If you hold down the shift key, and right click on an executable, you will see a Run As option in the pop up menu. Just enter your credentials, and you are running just that process as admin. You can do something similar from the command line, it just isn't as simple as su on *NIX. It is documented at http://www.microsoft.com/resources/documentation/w indows/xp/all/proddocs/en-us/runas.mspx.

Re:Users != Root.

[Anonymous Coward]

If it helps, the arse in question is 14 and thinks he's hot stuff because he has IIS personal edition installed on his overclocked "boxen".

People who use computers for actual work are always properly respectful of those who can chown their files away on a whim.

Re:Users != Root.

[ckaminski]

On XP it's called "RunAs".

-Chris

Re:Users != Root.

[rcamera]

now, now. be nice. the 'god-like-developer' needs you to mount/allocate more disk for him. his core files are growing at an exponential rate.

Re:Users != Root.

[Anonymous Coward]

I would agree.

If users do need fine grained control either the system is not correctly set up or virtualised environments are indicated.

Re:Users != Root.

[Anonymous Coward]

Hey AC, yes, it was.

Re:Users != Root.

[gte910h]

You know why LD_LIBRARY_PATH is a variable? So You can install libraries locally. That's what you do if you need libraries for an app you need to compile in your directory. Sounds annoying? Deal with it. It is the price of security

Re:Users != Root.

[jrwall0318]

As a developer, I agree; I don't need, want or care to have root on a live production machine that I am not 100% completely responsible.

However, on my personal desktop system, if IT doesn't give me the tools I need to do my job, I'm going to get it done, and that usually means getting root access (I have physical access - there's not much you can do to stop me). At one job it took the IT department 6 MONTHS to respond to my request to upgrade the video drivers for my graphics card so that I could use something better than 640x480 60Hz (this was 2 yrs ago). Needless to say, after 2 days, I fixed the problem myself with no adverse effects, and if the IT department had not taken so long to get to me, I would not have rooted my box.

Lesson Learned: Most developers don't care if they have root or not, but if the IT department can't or won't support them, they WILL subvert your attempts at security. To ensure that your systems stay secure, make sure you respond to the developers and users in a timely manner.

Re:Users != Root.

[Richard Steiner]

You're not a developer if you can't even maintain your own machine.

Most of the serious UNIX and mainframe environments I've worked in over the years kept the sysadmin and application software development functions completely separate.

The functions were performed by different groups in the IT department, and were populated by completely different people.

This often makes sense, since the skillsets required to admin a box tend to be completely different than the skillsets required to design/code/test/support applications software.

Re:Users != Root.

[aztracker1]

I wish I could mod you up even higher than 5... I admin a few servers of my own, but am primarily a developer, I personally don't want the admin privileges at work if I can at all avoid it. I have a pretty open set of servers at home, not to the outside world, but once in, it's a pretty soft center.

At home, I don't have to worry about permissions, as I am the only account, I have full acs... but in the workplace, I wouldn't want to think in terms of acs policies, etc. Let developers have enough rope on their own desktops to hang themselves, but *never* on a shared system/server. (myself included there)

Re:Users != Root.

[tomhudson]

If the developer isn't the best person to fix it, maybe he shuldn't have been screwing around with it in the first place.

If you can't fix it, don't break it.
If you do break it, you fix it - and if you end up screwing up really bad, well, maybe that's the feedback you need to teach you the lesson you obviously needed to learn in the first place
If you malloc it, you free it - or you make damn sure that it gets freed in all code paths, because you HAVE to clean up or its your fault when it gets p0wn3d

What's the point in hiring someone to develop software if they are going to spend half a day messing around troubleshooting their system
...
Besides, a developer isn't guaranteed to be the best person to fix a problem

... then they shouldn't have been messing around with it in the first place ...

Again, you screw it up, you fix it. I'll show you how to create an image for your system using dd, so when you DO screw up, you can restore it quickly. But if I just fix what you did, I haven't fixed the root problem (bad pun) - that YOU are the problem, and need to learn to take responsibility for your actions.

Want someone to learn to be a good cook? Make them eat their own cooking.

It applies to everything, including boxen.

Policy in most companies is not decided by employees mothers.

You'd be surprised. Gate's mother sat in on most board meetings for YEARS.

Re:Users != Root.

[ckaminski]

IIRC only root (except some REALLY broken systems) can 'chmod +s' a file.

Re:Users != Root.

[ckaminski]

I solve all requests for "TEST" root access capabilities by giving them vmware and some stock read-only images to create virtual machines from. You want to fubar said machine, just fine. It won't impact me at all. The risk of NAT/trojans is still present, but in a properly managed environment, that's less of a problem than system stability in general.

Re:Users != Root.

[squiggleslash]

It's possible to be a good developer yet not be competent to admin one's own machine.

Well, yeah, but the discussion seems to be breaking down after a relatively reasonable comment that if a developer has a "development box" that they admin, and they break it, they should fix it.

I don't normally side with the Tech Services people on Slashdot, because most of the ones who appear on Slashdot are, well, to be honest, power-crazed nuts, but in this case the OP was absolutely right. If you want the right to admin your own machine, it's natural you should be the one to fix it. Ask for help if need be, but don't expect someone else to fix your own problem. You're either competent enough to ask for a particular right, and should be responsible for exercising it, or not, in which case get someone else to do it.

The aforementioned TS.on.slashdot people tend to be grizzled veterans who have had to clear up more than one mess because a manager or CEO insisted that, because of their position within the company, they should have admin rights because they're all-powerful and all-powerful-control-over-their-own-computer will go with their job. After clearing up spyware and putting all those "files I didn't think I needed" back into C:\WINDOWS\SYSTEM32, the TS.on.slashdot people tend to get to the point they want everyone to have a version of Windows that gets reinstalled every time you reboot the computer. Even if I disagree with them, I'm not remotely surprised. The relatively simple principle of "Want above the norm? Know what you're doing, and take responsibility" seems a much better alternative. The TS people I deal with in real life do tend to consider that a founding principle, and I thank them for it.

Re:Users != Root.

[tomhudson]

Maybe you should talk to a fighter pilot sometime. They do a visual inspection before every flight. They KNOW their birds. And they know what not to tinker with ... which is the whole point of the article ... don't screw around with what you don't know.

Now, the fighter pilot isn't building airplanes - but the test pilot is! And he knows a damn site more than most pilots.

More importantly, the engineers building the planes have to know how to build and maintain them - they're writing the book on how to do it. So we're not talking about users here - we're talking about builders. Builders better know what they're doing, including how to maintain their machines, or they'll get bit by the same bugs over and over and over.

Developer != User.

Your attitude is that developers ARE just users, that they don't need to know what's going on "under the hood". So, what next - doctors who don't have to know about how the human body functions - just run through a checklist and then does whatever the book says, with no judgment? No thanks - I want a doctor who actually knows something about how my "execution environment" actually functions when he cuts me open.

This trend of being proud of "not knowing" is stupid.

Re:Users != Root.

[Anonymous Coward]

With developers like you about, why am I not all that surprised to see your 'god-like' positions going to Bangalore?

Re:Users != Root.

[SuperFunFunFun]

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. Just make sure your "no" isn't a career limiting decision. Back in the day, before I started my own company, I saw more than one situation where the IT flunkie told the CEO they couldn't have what they wanted. It was followed by a quiet call to the CFO who the CIO worked for that went like this, "Bob - can you have Frank (CIO) get me a thinkpad T9000? Also - I'm not sure that that guy Phil (IT flunkie) should be around our sensitive information. He seems to not understand how our organization's controls work." This conversation is usually completed with a call from the CFO to the CIO that goes like this: "Frank (CIO), I just got off the phone with Jack (CEO). Seems like he has a problem with Phil's understanding of how our company works and his role. Unless you feel otherwise, I'd like to replace him." If you are lucky, and things are going right for your boss, you might survive this. If not, you are going to get to read your job description on monster in about 48 hours. 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. I can assure you no matter what you do in IT that your work, even if done at 2 in the morning is not as important to the company and your own future as what most VPs and C level officers do on the golf course. That's why those guys do make $100K plus and even more if things are going well for your company. If you are going to try to enforce policy, it's much better to let the executive do it for you. Don't say no, simply ask if the exec has cleared it with your boss. Tell them that you can't do the favor unless it's approved and then volunteer to take it to your boss on their behalf - even if you know the answer in advance.

Re:Users != Root.

[tomhudson]

No problem ...

<clickety-click><clickety-click>

There - tons of free space.

Oh, what's that - your home directory is empty? Of course it is - you SAID you wanted more free space. Now you've got more free space than anyone. Just take your backup files and ...

Oh, you don't HAVE backups? You left them in your home directory? Gee, its a good thing we did this exercise today, and not a year from now, when a hard disk failure would have cost you another year's work. Here, let me fix you up ...

<clickety-click><clickety-click>

... restore ...
cp -r backups/archives/boring_meetings/notes/secret_pr0n _archives/kiddie_pr0n/gross_stuff.zip /home/luser/Documents/my_kids_birthday_party.zip

<clickety-click><clickety-click>

Okay, all fixed up. Oh, btw, the boss was wondering if you could email him those pictures of your kid's last birthday party. Everyone's been asking - so why don't you just cc the whole office?

No problem, always glad to be of assistance.

Re:Users != Root.

[MysteriousPreacher]

The thing is, this approach is designed to punish the developer and doesn't really help the business. There should be some kind of penalty for them but reducing their productivity doesn't strike me as a good one. At first glance it looks like nice swift justice but then burning down an arsonist's house seem like nice swift appropriate justice.

If someone messes up their work equipment then that should be handled through a disciplinary process but the most important thing is that they are able to continue their work as soon as possible.

I think this whole issue depends on circumstances. If it's a small company/department and time isn't a serious issue then having them fix their mistake could be useful. I've seen this done to good effect, particularly in a small design company.

In a larger group or a group under pressure, it's just not effective use of their time.

Regarding to cook analogy, are you trying to teach the developer to troubleshoot and if so, how is that going to help them in their job? If my job is to develop a calendar application, how will it help me to spend time learning how to remove dodgy kernal extensions that I installed when I decided to try some whizzy software I found on the web?

If I've been pouring coffee in the water cooler despite the sign warning against this, which option would make the most sense in a professional environment.

1) Have me leave my project while I fetch a mop and bucket to clean up the mess?

2) Have my manager discuss this with me so I agree not to do it again?

Regards his mother, someone had to be there to make sure he was wearing clean underwear.

Re:Users != Root.

[Bob Uhl]

The chown security issue is that if a system uses quotas, then user foo can mask his disk usag by chowning his files to user bar. Of course, on a system without quotas this isn't an issue, and it's just annoying not to be able to chown.

Re:Users != Root.

[djp928]

You know, this would be fine if developers actually had a clue about admining a system. All of them think they can, but I have yet to meet one who really can.

Here's what happens when you give developers control of systems. In about two seconds, every file they're working on becomes chmod 777, because they can't be bothered to learn to work within the security system. Then they wonder why, when the stuff is moved to production and the correct security priviledges restored (at BEST I would allow 775, but you'd be freaking stunned how often just taking away write priviledge from "other" breaks their shitty code), it wont run properly, or will only run as root.

I see this time and time again. They always claim "Oh, I run Linux at home" or "I've developed on UNIX for years" but then do basic, boneheaded things like that because they can't be bothered to figure out how to do it right.

I totally believe there are developers out there who also know more than I ever will about managing a UNIX system. But I've yet to meet one.

-- Dave

Re:Users != Root.

[tomhudson]

Thank you for quoting me properly:

You're not a developer if you can't even maintain your own machine.

Your own machine - not the group's dev machine.

If you can't even keep your own box running, you should be fired. You have demonstrated that you are not the least bit curious in how things work, and as such, will put forth the minimum effort to do the minimum amount of work to get paid.

There should be no room for intellectual laziness in this field.

Re:Users != Root.

[tomhudson]

You've never had to do a work-around for a buggy environment (*cough* IE *cough* Windows *cough* the first 3.x version of gcc *hork*)?

It helps to have an understanding of what's actually going on under the hood. It can give you a clue on how to test for edge cases so you can do a work-around that actually works, rather than just seeming to work.

As for the coffee in the water cooler - definitely send you for a mop and bucket. Better you "waste" 5 minutes of your time, than 5 minutes of yours plus 5 minutes of your managers, plus 5 minutes of someone else who is going to have to clean up the mess.

And while you're mopping up, I can lower your chair a few notches, grab your keyboard and replace it with that crappy one that's currently hooked to the server, stick a DOS boot disk in your cd-rom that has a copy of my old "BOOT_ERR" (a modified boot sector) on it so that next time you boot, you just get a whole bunch of error messages informing you that your CPU is now fried, and all sorts of other goodness for screwing around with the coffee :-)

Because rule number 1 is don't screw around with the coffee!

Caffeine is important to the success of any project :-)

Re:Users != Root.

[Anonymous Coward]

Tried that:
chmod 4755 file
sudo chown root file
-rwxr-xr-x root root file

chown kills suid/sgid bits.

Re:Users != Root.

[schon]

No developer worth his salt will ruin a desktop machine. Someone who either on purpose or by accident comprimeses his machine should be fired.

What a great system.. just one question: where do you find people who are guaranteed never to make a mistake?

Re:Users != Root.

[Constantine XVI]

There's also a tool called "SUperior SU" that has similar functions to *nix SU, including launching another desktop (even on pre-XP systems) http://www.stefan-kuhr.de/supsu/main.php3

Re:Users != Root.

[BrenBren]

For one of my past positions, I had to support a group of kernel developers. Their job was to work on a product that was basically a customized FreeBSD kernel with a fair amount of software that allowed the Admin to tell it how to work.

For some odd reason, many of these people had no clue how to do things in FreeBSD. I had to do it all for them, and heaven help them if they tried to change crucial system configurations....

Re:Users != Root.

[tomhudson]

Thats why computers and politics mix so naturally nowadays - "Those who can't, do!"

(- this message brought to you by the George "Mr. Chimp" Bush for Visual Basic Mascot" committee)

Re:Users != Root.

[BrenBren]

People who use computers for actual work are always properly respectful of those who can chown their files away on a whim.

You apparently don'tknow the people in Dev Group where I'm working now. Several of them don't seem to understand that "dev" environments are for debugging, so that the code doesn't bring the world crashing down when it gets released. One guy manages to write code that brings high-end servers to their knees like clockwork.

I think you mis-spoke with your use of "always" there. Perhaps you meant "usually" or "almost always"?

Re:Users != Root.

[LWATCDR]

"They tend to care about the typical concern of ordinary software, without having a clue about numerical accuracy, the need for verification/reproducibility of the result etc."
What the heck??? These guys come from a CS background??? CS is supposed to stand for Computer Science! Typical concern of or ordinary software? I call working a concern of ordinary software!
To me it sounds like you are working with some very low level applications programmers and not people with a background in Computer Science.
Of course we did hire a developer once that had a degree in CS but didn't know what a hash was. He didn't last long.

Re:Users != Root.

[MysteriousPreacher]

heh heh. Okay, I'll stay away from the coffee.

Re:Users != Root.

[Shadowruni]

I'm not THAT stupid. I do let my boss know what's happening and I usually deflect blame onto him. As far as the 100K+ guys go, I'm not refering to execs... I do believe they earn it (watching my CFO seemingly almost commit karoshi trying to get our last round of funding convinced me of that). It's devs who believe they walk on water and do things like create arrays so they don't need pointers (I know I know doesn't make any sense to me either but that's what HE ACTUALLY SAID). And I watch these guys get paid more in a year than me and my wife make combined. It is infuriating but I try not to let it get to me 'cause like my momma said, "What he eat don't make you full.".

Re:Users != Root.

[BrenBren]

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.

I know many who feel like they have to tweek their working environment (background, sounds, screensavers, etc.) almost constantly. It's a wonder they get anything done, and it's certainly a wonder they still have a job.

Policy in most companies is not decided by employees mothers.

Perhaps it should be... At least then, they might be more inclined to work instead of IMing their buddies in the next state or playing with their system settings.

Re:Users != Root.

[Antique Geekmeister]

This brings up a vital point: for compute clusters, you absolutely need a good, solid, easily installed OS image. You can use it for VMware setups, new hardware installations, testing new configurations, and scrubbing a machine after some developer with root has committed absurdities. You can also use it as a matter of scheduled system upgrading, to make sure that no weirdnesses have crept into one machine that are not universally present and interfere with work.

Re:Users != Root.

[theOnlyTPC]

No, the chown security issue is that if a user can set the suid bit on a file, and then chown it to someone else (e.g. root) then you just created a window for local privilege escalation.

[tom@builder]~$ cp /bin/sh .
[tom@builder]~$ chmod u+s ./sh
[tom@builder]~$ chown root ./sh
[tom@builder]~$ ./sh
builder# id
uid=1001(tom) euid=0(root) gid=1001(tom) groups=1001(tom), 0(wheel), 5(operator)

D'oh!

Re:Users != Root.

[thogard]

chown (on systems where any user could use it) would AND mask the perms to 0777 before the new ownership. There were a few systems that did it after the ownership and if you were quick you could create and start a setuid program.

Re:Users != Root.

[Bob Uhl]

That's easy enough--clear the suid bit when ownership is changed. This should probably be implemented in the kernel, so that not even root can get around it (he can chown, then chmod like everyone else...). Not a big deal. In fact, I thought that this was the way it works already?

Re:Users != Root.

[Anonymous Coward]

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.

Wouldn't it be great if everyone in government actually felt this way?

You, sir, should run for office :)

Re:Users != Root.

[Anonymous Coward]

Nope, only the owner (and root) can chmod +s a file, but it's not a problem, since chmod +s does not mean "run as root", but "run as the owner".

However, chown'ing a file nukes the set*id bits, for a good reason.

(The last one might need to be tested on $OS of choice, but I would say any secure OS does this).

sudo chmod == pwnt

[qweqazfoo]

Ever heard of setuid root?

Re:sudo chmod == pwnt

[noz]

Where I used to work we had an in-house program which was suid root which parsed the command line and executed, on behalf of the user, the correct underlying privileged commands or system calls. They could run

$ super mount-usb-drive

to get their thumb drive online, or

$ super web-only public_html

to change the group of their home page to www. Simple and safe.

Re:sudo chmod == pwnt

[chgros]

Where I used to work we had an in-house program which was suid root which parsed the command line and executed, on behalf of the user, the correct underlying privileged commands or system calls.
You know what sudo is right?

THis is where I miss VMS

[Billly Gates]

ACL's are quite nice and so are different levels of security.

Re:THis is where I miss VMS

[slashjunkie]

Several filesystems on Linux have support ACLs for a couple of years now... ext2/ext3, ReiserFS, XFS....

Re:THis is where I miss VMS

[foxhound01]

Yeah, ACLs are nice. A buddy of mine tore one of his while playing football almost a year ago and is just now getting to where he can walk normally.

Re:THis is where I miss VMS

[Anonymous Coward]

ACL's are quite nice and so are different levels of security.

Interesting that no one (modded to +4) has mentioned that other popular OS that uses ACLs for security. Not that it would relevant in any way, of course.

Re:THis is where I miss VMS

[xiphoris]

You mean Linux? As another poster mentioned, Linux has had ACL filesystem support for a loooong time.

Tie them up!

[Anonymous Coward]

We usually just tie them to their chairs with duct tape. That way we always know where they are, and what they've done (the video cameras help).

Re:Tie them up!

[boarder8925]

We usually just tie them to their chairs with duct tape.

That duct tape's got to put a strain on their use of the computer, what with their arms immobile and all.

But worse yet, think of the residue the duck tape will leave on the chairs!

Re:Tie them up!

[eln]

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.

Re:Tie them up!

[catch23]

duck tape is a brand of duct tape... so it's sorta like making a xerox copy...

Re:Tie them up!

[boarder8925]

Well, no, I've always written it "duck" tape. It's easier for me to pronounce it in my head as "duck" instead of "dukt." ;)

Environment?

[Anonymous Coward]

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-Oxley?

[pbrammer]

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.

Two names...

[toupsie]

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.

Re:Two names...

[Anonymous Coward]

Change Control - if you want a secure IT environment, you don't let just anyone make changes - whether it be administrators, business owners, etc. How do you know the change you're about to make isn't going to affect other applications or services? ITIL would be a good starting point for reading

Re:Two names...

[The_Xnuiem]

And here are the joys of working for a company based in the UK. S&O doesnt apply. Until the House of Lords decides to pass something similar at least.

Re:Two names...

[toupsie]

Good point. Change Control is an important part of in place processes for rights management.

Re:Two names...

[Anonymous Coward]

Follow the procedure or go somewhere else to work.

That's fine. You just remember that the point of a work computer isn't for that computer to be secured; it isn't there so that access logs can be made for it, and it isn't there so that you have a system to hover over and say, ``I keep this system secure.''

That computer system is there for people to use to do work, and your job is to move Heaven and Hell to make sure that the people using that computer system can do their jobs. Your job has no point if people aren't able to use that system to get work done. You aren't some annointed gatekeeper to a company's systems; you're an enabler for other people to produce meaningful products.

Even braindead admins (making no accusations and pointing no fingers) can manage to set a system up securely given the guides and support available to him today, and he can keep that system secure by denying all access for any request out of the ordinary (or more likely, any request above his level of knowledge).

Naturally, a stupid request (ie, a request for far greater power than necessary to enable something needed for work) for powers is just as silly as a stupid admin (or an admin with his head inflated to thrice its normal size), but at least a stupid request can be denied with relatively little trouble. A stupid admin is a problem that can linger.

In short, get me the resources I need to do my job (and none past that), or get the fuck lost.

Re:Two names...

[Anonymous Coward]

> 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.

Re:Two names...

[Anonymous Coward]

The system also isn't there so you can play with it. It's there to make the company money

Right. That company needs specific tasks accomplished. When I've been hired to perform those tasks, then I expect them to be done (because I'm going to do them). Luckily, we're using UNIX (or a workalike), and so I know that the tools exist for me to be able to get these tasks accomplished.

if your inflated ego gets in the way of that [making the company money]

I don't have an ego. I'm there to do a job, and the admin is there to set up the environment so that I can perform this job. I don't care how he does it, except that I care a lot about security.

There's a demand for lists of personal and financial information, and so identity thieves and their ilk are stretching after it. I have a keen interest in keeping this information private and go through great lengths to do so on systems that I control. The admin either does the same thing, or he isn't doing his job.

(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.

When Standard Operating Procedure means denying any request for new programs, updated versions of libraries, or anything at all, then it absolutely needs to be screwed with; furthermore, I didn't mention anything about production work or production systems, but if a task demands that a production server be updated or changed, then it's not the admin's job to say ``no.'' It's the admin's job to make it work and make it secure.

An example might be where a server app is developed on a Linux whitebox using APIs that will access accelerated hardware on a production server. When we get ready to test on the real thing, we'd better have access to test machines, because we won't deploy onto a production server untested, no matter what some admin says. Other than that, we don't care what we're testing with. And when we get ready to deploy it, the production server had better the hell be updated and ready when we're ready to deploy.

Nobody said anything about getting out of change control or limited access. This is UNIX after all. The job can be done securely.

No one said anything about not giving you what you need, they just said you don't need root.

They don't decide what I need; the task dictates what must be done and how, and I'd damned well better get whatever ``it'' is. Again, this is UNIX, so I likely don't need root, but I probably didn't ask for it in the first place.

if there is a lot of things you need done, then there's probably a larger problem to fix.

Like egotistical admins who slap down every request on general principle, or lazy admins who can't be bothered to set up sudo correctly, or incompetant admins who are put in the position of having to do something outside of their skill set.

Re:Two names...

[timbrown]

It's called Basel II.

Re:Two names...

[Knara]

Wow, have issues much?

Yes, it's the admin's job to enable you to do yours. Within reason.

However, since they are the admins, and you're the "incoming", then it's good practice to understand why things are done the way they are, before deciding that the reason you're not getting your way is because the admins are power-mad BOFH's.

In spite of what Dilbert has so cleverly shown, it is not out of the realm of possibility (and commonplace) for there to be procedures in place for a reason. Furthermore, environments are so varied that what might be a "sure, we can do that" at one company, would be a "no way in hell, and here's why" at another.

Basically sounds to me like you're a developer-brat with a chip on his/her shoulder when it comes to admins that don't jump the very second you command it. Keep doin' that. Hopefully you'll run into a BOFH who actually has management support and get shown the door. Sadly, that'll probably have little effect on your personality problems, but I'd pay to see it, nonetheless.

Re:Two names...

[Anonymous Coward]

Yes, it's the admin's job to enable you to do yours. Within reason.

Wrong. It's the admin's job to get me the tools I need to do my job within the bounds of security. No other factor is valid grounds for turning down privledges.

However, since they are the admins, and you're the "incoming", then it's good practice to understand why things are done the way they are, before deciding that the reason you're not getting your way is because the admins are power-mad BOFH's.

It sounds like you're trying to cast me as the newbie. That's wrong. I'm an expert at what I do (development) and know the issues involved with administration; although I'm not an expert at it (if I did it for a living, I would be). It's not hard to tell when some admin is trying to blow smoke up my ass, and I don't care if he's doing it because he's lazy, because he's stupid, because he is actually a power-mad BOFH, or some combination thereof.

Note that extreme preoccupation isn't on that list. Admins have to prioritize their work the same way other folks do.

In spite of what Dilbert has so cleverly shown, it is not out of the realm of possibility (and commonplace) for there to be procedures in place for a reason. Furthermore, environments are so varied that what might be a "sure, we can do that" at one company, would be a "no way in hell, and here's why" at another.

Nobody is suggesting circumventing intelligent procedures. The whole reason I started posting in this story is because the sense of almost every post in it is laughably misaligned with the real world (leading me to believe that it's mostly admins posting in it (all the developers who aren't on vacation are too busy working)). The admin's job is to fulfill the needs of developers. If he _ever_ answers ``no way in hell,'' then he's not doing his job and needs to be traded in for a better model. Again, this is only in response to requests for the proper resources. Requests for the one and only root password to the main production server don't count, although I'm not surprised you can't make the distinction. You seem to be dead set on defending the admins above the developers, when it's really a symbiotic relationship. The only qualifier is that without the job needing to be done and developers needing secure computers to do it (and not having time to admin the computers themselves), there'd be no need for administrators.

when it comes to admins that don't jump the very second you command it.

But that's his job, adjusting for common sense, of course. (Since you sound like bleating, stupid admins I've dealt with before, here's the definition: common sense. You need to click on the different colored words, and it'll take you to a page with the definition.)

Basically sounds to me like you're a developer-brat with a chip on his/her shoulder

That's your opinion. Keep doin' that. Hopefully you'll run into a BOFH who actually has management support and get shown the door. Sadly, that'll probably have little effect on your personality problems, but I'd pay to see it, nonetheless.

Around here, our admins have developer support. When a developer is having to doing the admin's job as well as his own, or worse, counteract bad actions on the part of the admin, then it's time to show that admin the door.

As for my personality, it makes my company money. I have good relationships with people around me (admins included, because we've got some damned good ones who know their shit). I just have little suffering for fools and even less tolerance for broken policies that hold the opinions of fools in high esteem.

It's dangerous to have the decisions made by any position be set in stone because of what can happen when a fool holds that position. Wow, have issues much?

No, because our admins are terrific.

Re:Two names...

[Knara]

[troll filter engaged]

Wrong. It's the admin's job to get me the tools I need to do my job within the bounds of security. No other factor is valid grounds for turning down privledges.

No, it's the admin's job to allow you access to tools you believe you need, within the boundaries of organizational policy. In an ideal world, you may be right, but in the real world, admins can only provide as much access as policy allows, and admins frequently have limited (if any) input into policy.

The admin's job is to fulfill the needs of developers.

No, the admins' jobs are to provide for stable, secure infrastructure that contributes towards the central mission of the organization. This organization may or may not consider their developers particularly important, or necessary, and as such, their requests carry widely varied levels of importance.

Around here, our admins have developer support. When a developer is having to doing the admin's job as well as his own, or worse, counteract bad actions on the part of the admin, then it's time to show that admin the door.

Sounds like this is the source of your overreaction. Understandable, but your ideas of what the job of an admin is are still skewed.

I just have little suffering for fools and even less tolerance for broken policies that hold the opinions of fools in high esteem.

Aside from the awful time I had parsing that sentence, it sounds to me that you don't understand the idea of policies, or furthermore how to encourage your organization and/or group to re-examine policies that are no longer practical, or not flexible enough.

[/troll filter disengaged]

Furthermore, one doesn't need to be a "newbie" to have unrealistic or skewed views of how a business runs (or should be run). I know plenty of people with long resumes who don't "get it" either, on a variety of topics.

It's just not safe...

[Jamori]

Allowing root access on a knowledgeable user's local machine is one thing, but multiple arbitrary people with root on your main cluster is entirely another matter. There are simply far too many chances of one of them "accidentally" doing something they didn't mean to and borking the system. That's definitely not an issue you want to deal with.

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.

Re:It's just not safe...

[Jamori]

By the way .... I speak from experience on a small server I ran for my friends and myself. I got tired of tweaking things for them, setup some extra permissions for the ones I thought I could trust, and regretted that decision for the next several days.

Re:It's just not safe...

[ashridah]

And, of course, the far more fun variant is the "pissed off worker's revenge", where they use

sudo chmod u+s /bin/sh /bin/sh
and then proceeds to remove the entries in the logs that talk about them running 'sudo', making a copy of the setuid /bin/sh, and restoring the permissions.

Not so helpful if syslog is logging to an external server or a line printer, but people need to analyse logs for that to stand out, and if you've given them carte-blanche sudo chmod access, they could bury it in a sea of normal looking chmod's, and then it becomes needle-in-haystack-like

ash

Re:It's just not safe...

[aralin]

If I do have a sudo chmod, all I need to find is one file that has an owner root. Lets say a /tmp/owned. Then I can do the following commands:

sudo chmod o+w /tmp/owned
cp /bin/bash /tmp/owned
sudo chmod u+rs,o+rx /tmp/owned
/tmp/owned

And I have a shell root access. So that is why I don't give a sudo access to any command unless I want to give a sudo to bash.

Re:It's just not safe...

[c0dedude]

It's always the users who care whether they have root who should have it the least. I had been doing some configuration so sudo was left cached, I left my room and went to grab a soda, and a user walked across the hall and added himself to suoders. WTF?

Re:It's just not safe...

[fitterhappier]

Recovering from this sort of sabotage, and from the setuid root /bin/sh trick described in another reply to the parent, is easy when you're managing the system with radmind.

radmind detects changes to files (size, modtime and optionally checksum), owner, group and mode. The administrator then has the option to reverse those changes, or capture them and apply them elsewhere.

Re:It's just not safe...

[ianezz]

And I have a shell root access

Just a note: your point is absolutely valid and correct, but please don't use Bash as an example, because it is one of the few cases where this don't work. Bash always resets the effective user ID to the real user ID, basically making it impossible to have a setuid bash.

Of course it will work with other shells and programs that can start commands.

Cynical answer

[Theatetus]

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.

Re:Cynical answer

[Anonymous Coward]

If that's how you justify your job, you are missing something fundamental. The need to "appear" to be necessary is fucked up.

Re:Cynical answer

[Anonymous Coward]

Welcome to reality, where people act in their own self-interest. We should appreciate his honesty so that the managers among us can act in their own self-interest and fire people like him.

BTW,
cynical: based on or reflecting a belief that human conduct is motivated primarily by self-interest

the way I do it...

[Heem]

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.

Re:the way I do it...

[Vellmont]

I think your shop is pretty typical. For a software developer there's a lot of reasons why you should give them root access to a non-shared machine they use for development and/or testing. Giving root access to a developer on a shared, production machine, no matter how competent an administrator they are is just bad policy.

Sudo on shared test machines can be a bit more liberal though. Much of the time developers need to start and stop services multiple times a day, if not an hour. It's impractical and extremely inefficient for a developer to have to ask an admin to do this multiple times an hour.

What I'm getting at is sudo should be relegated to high-level tasks like starting a specific service, and not low-level tasks like (gasp) chmod and mv. You can easily do an ENORMOUS amount of damage with the wrong sudo mv command.

Re:the way I do it...

[Heem]

and as good a developer or QA engineer they may be, they are not the ones accountable for the systems. at the end of the day, I, and only I am accountable for building and maintaining good systems.

Re:the way I do it...

[thesnarky1]

I think you're absolutely right in this. In my mind, it's all a matter of damage control. If someone screws their (personal, not shared) development system you're out one programmer for maybe a coupla hours. If someone screws a production server, or something a lot of people use, everyone's down until it gets fixed. In my mind, a user should never be allowed permission to do something that could affect more people then themselves, unless they are well-trusted. Such as an admin in this case. They get permissions because they are trusted to not screw something up, and be able to fix it even if they do.

Re:the way I do it...

[Anonymous Coward]

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

Novell?

Re:the way I do it...

[tyler_larson]

You are going to get a bunch of responses. most of them from people that will say something like.. "NO." "NOBODY GETS ROOT, PERIOD".

And, of course, "Shame on you for even asking!"

Even the "innocent" looking commands like chown and chmod can have profound effects when run by root (setuid anyone?). Logging behavior is no solution--you'll have the logs, but the damage will be done. And as with any other r00ted system, the extent of the damage is never really certain. Even the integrity and completeness of the logs would be suspect.

Giving users sudo access is giving them the ability to execute any attack you haven't specifically guarded against. If there's any priviledged operation that users need to perform, it should be properly wrapped in a tightly controlled setuid binary.

Re:the way I do it...

[ryanov]

You won't even have the log, if it's local and the user removes it.

Re:the way I do it...

[Anonymous Coward]

"She Could Dance a Cajun Rhytym.. Jump Like A Willys in 4 Wheel Drive.."

WTF? Are you on dope?

Re:the way I do it...

[lachlan76]

Someone who thinks chmod is an innocent looking command needs to get slapped.

Apart from the setuid threat you mentioned, there is also the opportunity for someone to take home a copy of /etc/shadow.

Re:the way I do it...

[xsonofagunx]

I bet it's Microsoft :)

Re:the way I do it...

[jhantin]

You won't even have the log, if it's local and the user removes it.

Big whoop. You really need that kind of analysis, shut the box down and run a directory by directory, file by file comparison of permissions and content hashes. If integrity is critical, then you did take a baseline inventory of the filesystem contents to compare against, didn't you?

Re:the way I do it...

[Aneurysm9]

Since he appears to be a Deadhead, yeah, probably.

Re:the way I do it...

[Anonymous Coward]

No, Novell is not in Connecticut. Now the questions that remain are: why was the grandparent arrested for drunk driving in 2000 at the age of 23, had he been drinking Jägermeister, and why does he keep his Livejournal friends-only? Anyway, have fun with your land rover, Jim. :)

Re:the way I do it...

[Trillan]

This immediately made me think of a Fight Club quote.

"Which software company do you work for?"
"A major one."

Re:the way I do it...

[pete-classic]

"Are there a lot of these kinds of bugs?"
"You wouldn't believe."

-Peter

Re:the way I do it...

[rdebath]

> Even the "innocent" looking commands

Innocent!

chown me /etc/passwd
chmod 666 /etc/passwd
mv cp_passwd /etc/passwd
cp cp_passwd /etc/passwd

Yea Right! Innocent!

Re:the way I do it...

[@madeus]

You are going to get a bunch of responses. most of them from people that will say something like.. "NO." "NOBODY GETS ROOT, PERIOD".

That would be correct.

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.

That would be wrong.

If your giving users root 'to get things done' it's because you have set up their environment badly.

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.

You ought to have a netboot/jumpstart system in place so that users can do this themselves.

However, the "real" servers that are accessed by someone that isn't themselves, the users do not get the root password, ever.

You should be aiming a lot higher than that - on a production server with sensitive data nobody should have root, not even the administrators (because you really shouldn't be relying on DAC alone in that sort of environment - you should have MAC, devolved permissions, four eyes authentication, etc.).

Re:the way I do it...

[subreality]

That would be wrong. If your giving users root 'to get things done' it's because you have set up their environment badly.

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?

Re:the way I do it...

[afabbro]

I also work for a big Fortune 500 company. The problem is not enforcing "only the sysadmins get root," it's that many software vendors write shitty software that needs root.

Some examples:

• Oracle is very well-behaved. Upon installation, root has to run one root.sh script to set perms and make directories and after that, the DBAs do their thing and we do ours. Perfect.
• Websphere is a nightmare. Lots of things owned by root. In fact, most IBM products are this way - TIM, TAM, AMOS, most Tivoli crap, etc. They stick stuff in /etc all over the place that's owned by root, change system configs in /etc, etc. Sure, you may only need to do it at install time, but installation may be an all-day event, highly iterative, often different, and (in some environments) frequent. Are your sysadmins going to sit with the Websphere team every time they need to install another copy of this crap?
• HP OpenView.
• Control-M. And AUTOSYS, if memory serves.
• Apache. Owned by root, started by root. Who's going to restart it every time the developers want to make a change?
• MQ.
• Oh, and SeeBeyond, eGate, and a zillion others.

Of those, apache is one of the better ones...if you make a mechanism for the developers to stop/start apache (sudo, groups, binary pass-throughs that are setuid, whatever) and chgrp httpd.conf, you can usually satisfy their needs. But of course, for a box that's a webserver, if you give someone the ability to stop the webserver or change its config, that's about as big a security hole as giving them root.

root is not the only important account. With root, I could do complete damage to our production Oracle systems. But if I had the 'oracle' account, I could do just as much from a business point of view (erase the database files). In fact, with 'oracle' I could do more damage than having root - with root, I could erase the database and everyone would know it. With 'oracle' I could connect and change values in tables and no one may know for a while.

Etc. There are a lot of apps that expect to have root. I know, in your shop, you wouldn't allow them to be installed...try telling that to the CFO/CIO who's paying for the servers and your salaries. In some vertical markets, there are only one or two apps to choose from...you live with their requirements. And even something like WebSphere, where IBM should know better, is impossible to install without having someone with root standing by or doing the work. If it's something homegrown, you can perhaps get by with groups, etc...if it's something from a Big Vendor, you can't really change how it's installed or they won't support it.

Often it's a case where either you have your sysadmins become experts in a dozen different middle-ware apps (blech) or you share root somehow. You can limit damage with sudo, special binaries to start/stop things, etc., but ultimately it's a tradeoff. Is package X worth more to the company than the security problems it creates? Often it is.

Re:the way I do it...

[Anonymous Coward]

Preach on. The other thing I had some minor success with was to run all my servers using, believe it or not, Mac OS 7. Now before you jump up down here is why: old macs are cheap, reliable, and repair is a snap. I used that for production, a simple script kept each user to sperate hard drives, scaling that was simple: new user, new drive. Tape back etc. No worries about "root" or screwing it up horendously. Litterly the worst they could do was move a small app called 'desktop' and even that didn't seem to screw anything up the one time they did. For the office: a read only serverlet, for their "personel" use typicly a laptop or some sort of terminal. The unspoken rules were: screw around with your laptop till you get RSI Syndrome, tha production server remains mac, and never ever ever have one "main" os. The companies record for viruses? About mabie, one a year, typicly limited to 5 people.The servers had a uptime of around--- mmm 200days, however powering down at night to save wear and tear when i left lead to uptime around 12-13 hours. No BFD.

Re:the way I do it...

[ldspartan]

Given that apache is (generally...) binding to a priveleged port, how do you propose it do that without being started as root?

Re:the way I do it...

[@madeus]

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?

To manage something like Apache with sudo, the effort required is really small:

e.g. in sudoers conf:
>User_Alias WEBMASTERS = bob, jane, sue
>WEBMASTERS ALL = (root) /usr/local/sbin/apachectl start, (root) /usr/local/sbin/apachectl stop

As a user, seeing commands you can run with sudo is as simple as 'sudo -l', you can always put a note (with an example of how to do it) in the motd (I've tended to do that myself).

If they are doing software development and have requirements that include things like the ability to experiment with privilage seperation or modify iptables rulesets, then I'd definately have given them VMware (thought I'd probably set up a GSX server in preference to individual client installs of VMWare).

Tools like VMware and Virtual PC are a lot easier to manage than a bunch of desktops and a far better environment for testing and developing in - when someone screws up, they can revert to a previously saved version of the system, or click to make a new instance using an existing image (allowing them to create a version based on whatever distro/OS they need to - for those doing work involving multiple platforms, or with a tendancy to break things).

As well as being easier (for developers and for those supporting them), it's ultimately a lot more useful thanks to things like the ability to easily revert to 'known good' images and to clone systems for testing. It also works out a lot cheaper than buying physically seperate development hardware for each developer (and reduces the downtime for users that comes from only having a single desktop for development and general use).

The 'live production' varient, ESX Server is really cool too (but that's a bit OT).

XEN

[Anonymous Coward]

xen is the king. ( http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ ) Many ISP who prowide virtual hosting provide you a xen machine instead - you have a full root access in a chmod jail, they have several VMs w/o perf penalty. Not your case though...

Re:XEN

[Anonymous Coward]

a chmod jail?

Do you have the slightest idea what Xen is?
Do you have the slightest idea what you're talking about in the first place?

with Xen, or VMWare, there's no need for chroot you give them full access to their virtual machine.

Re:XEN

[ckaminski]

In theory, with Xen and VMware, there's the possibility to get at the hosts filesystem and devices. With a chroot jail, you add another layer to help prevent that. It's by no means perfect, or even necessary in most cases, but it certainly doesn't hurt.

At the risk of saying obvious

[superwiz]

Have them share a group? They can always share files by allowing complete group permissions, can they not? If that is all they want to do.

Nope.

[Onan]

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.

Support support support

[Anonymous Coward]

Some of the systems I work on (high end compute clusters used by hundreds of researchers around the country) are very very restrictive. Do whatever you want inside your ~, but nothing outside. Why would someone need to change the permissions on a dir in /usr? /lib? It's a live system, and clusters need to stay up :-)

Need some software installed? Hell yeah - call support. Want to make it less frustrating for users? Have really really good support people (person), who knows the system VERY VERY WELL.

No way in hell!

[Anonymous Coward]

If you let developers change anything at all on a machine, change control goes out the window. When they deliver their product and piss off to a better paying job elsewhere you have no way to reproduce whatever weird arse thing they did to get their software to run.

Keep root away from developers and other users. Always. Never ever give in. Relax your guard and you will be bitten!

Imagine a Beowulf cluster of

[davidwr]

Oh wait. Okay, everybody can groan now.

Seriously, people should have the minimum permissions necessary to do their day-to-day jobs.

When it comes to things they might need to do occasionally, you have to decide is it worth the risk to give them that level of permission.

One way that might work is allow "sudo for a day" with management approval. If a person needed to do more than one thing in a day (or hour, or week) that needed extra privilages, have his manager and the IT manager sign off on it and give him those extra privilages for that time period. In some cases, this might mean adding him to the sudoers list.

If it's just a single task, like install a package, might as well have IT staff do it since it'll be just as much work to get management approval.

not root, but .....

[skelley]

.... 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.

Re:not root, but .....

[Antique Geekmeister]

You should be able to get around the 32 group limit with netgroups. I haven't run into that problem, myself.

You're very lucky to have such educable users. I deal with a lot of people coming from the Windows world who didn't even realize when what they were doing was broken beyond imagination, because they always had local "Administrator" privilages and absolutely needed it because hardware drivers did not work without it.

Re:not root, but .....

[nrc]

This is the same way we handle it. Each application has a user and group. We allocate a filesystem (or two, or three) for that application and they have ownership. They have sudo rights to su to the application user and to run as that user (sudo -u).

Once you take away the root crutch the developers learn to work in an environment with group access control. They get used to it and the need for outside intervention for chmods and such becomes minimal.

One of the rare instances where actual root access is needed are for servers that require low port access. In that case we give them sudo rights to run a startup script that is controlled by that admins.

Re:not root, but .....

[skelley]

We just don't let them use low ports. They have to bind to something over 1024 (we have a allocation based on app id). If they are surfacing an web site or that needs port 80 or something else like that with direct user connections the load balancer will do the port mapping when it forwards the requests.

Root in dev environments only.

[Uhh_Duh]

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.

Re:Root in dev environments only.

[{X-Frog}]

yep, I totally agree with you.

I always ask users to install their applications under an application username and group, this stop all problem and software/dba admin can do their job without asking someone else to run a command.

If this is an old application that must be run in root, I add some of the command that he must use, for that application only, in a sudo file. It doesn't cause problem if you inspect files/script before adding them to their sudo.

Developpers and dev-group/machine, in my experience, always had their own systems, with root access, in a different network. All I do for them is installing the system and configure the network, after that, it's their machine and if they ask me to repair it, they must have a pretty good reason (and escalation)! hehe

Re:Root in dev environments only.

[Knetzar]

My problem comes from when I see operations not have root on production servers. They need to call another group to do server specific stuff even though their app is the only thing running on the server. Does that make sense?

Re:Root in dev environments only.

[GoofyBoy]

Yes it does.

Its usually the other group's reponsiblity to have the box and app running. That means changes are well communicated and planned, not ad-hoc.

Also, its to make sure the single app is the only thing running on the box.

Also, its to make sure that there is a known level of security on the box.

Re:Root in dev environments only.

[Knetzar]

I'm sure that's a good idea, but when the team that owns the box is overworked, it can slow things down.

Re:Root in dev environments only.

[duffahtolla]

That is the price of stability.

Re:Root in dev environments only.

[aaronl]

That's a management problem. They need to hire more staff so that the job can actually get done. Allowing the situation to become half-assed because of that will not only get production shut down, but it will let management know that they don't have to solve the problem, because you will "solve" it for them.

Let me be the first...

[TubeSteak]

To suggest that you install a rootkit on the computer you need to use.

As for keeping them 'in line' once they have root access... I recommend a pointy stick.

Umm... or training. Even knowledgeable users can accidentally forget to reset permissions up and since you're a gov't contractor, you have to be more careful about data security. Right?

Home-grown setuid programs are dangerous

[Anonymous Coward]

If you don't do them right, users can exploit the IFS and PATH envvals to subvert your setuid wrapper program.

I couldn't do my job without root access

[unixpro]

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.

Re:I couldn't do my job without root access

[GoofyBoy]

>I am a developer of multiplayer servers. For my part, I couldn't do my job without root access.

If you are a developer, you don't need root access. All the examples you've given are the system admin job (system administration?)

>Don't make blanket policies unless you're prepared to make exceptions.

Its not really a blanket policy if there are exceptions.

Re:I couldn't do my job without root access

[Onan]

If you're messing around the the date and compilers on live production servers, you've got bigger problems.

If you're doing these things on a development system that's hermetically sealed from the production environment, that's only medium bad--but it's also a separate issue from what the original submitter seemed to be asking.

Re:I couldn't do my job without root access

[Anonymous Coward]

Your helpdesk/sysadmin(s) are incompetent. You should not need to set the date; NTP was invented for a reason. Assuming there's more than one developer, upgrading compilers is something that should be done regularly; and I wouldn't want your shiny new untested compiler upgrade introducing bugs for other users. Appropriate permissions in /usr/local/bin or /opt/mydevel/bin is a better idea.

In reply to the original post, give me chmod and I'll be root before you can blink.

Re:I couldn't do my job without root access

[Karma Farmer]

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 come from the other side of the fence. I am a developer of complex client-server applications. For my part, I don't even have login permissions on production.

I have root on my local development machine and shared development. If there are problems during testing, I get a temporary logon on stage, with an admin sitting over my shoulder watching me type. But I've never had a logon on production, and I can't imagine why I would ever need one.

I develop the app. I write deployment, testing, and rollback documentation. That way, I never need to touch the production server. This is how every real shop I've ever been in works.

Re:I couldn't do my job without root access

[golgotha007]

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.

I don't understand this. If you're a developer, and your development environment is Linux, then what the hell do you have a windows machine sitting on your desktop for?
It sounds like your desktop machine should be linux, then you can have root access to it, install all your necessary programs and carry on.

C'mon man, use the right tool for the right job.

Re:I couldn't do my job without root access

[kernelpanicked]

LMAO, you seriously didn't say what I think you did, did you?

You start off saying that you need root access to do your job and then admit that if you had it you use to dick around in /bin and replace the system compiler repeatedly. This is why only a complete moron would give root access to developers.

Re:I couldn't do my job without root access

[Gothmolly]

Nice troll. Let's examine: username of 'unixpro', subtle hint of being a gamer, poor knowledge of Unix (install to /bin? are you fscking serious?), the word 'Windoze', poor knowledge of Windows (yeah TRY and install everything as a user and see how THAT breaks, why do you think everyone ends up with local admin?), subtle clue that there's a Linux client for an online multiplayer game, whiff of moral relativism, and a cheesy strawman example. Yep, troll.

Re:I couldn't do my job without root access

[cortana]

Or even better... configure --prefix=$HOME

Re:I couldn't do my job without root access

[covertbadger]

If you're messing around the the date and compilers on live production servers, you've got bigger problems.

Hah, that's nothing. I've worked at a place where the budget was too stingy to spring for a test environment, so changes and upgrades to a business critical system were 'tested' by pushing them out to the live server and letting approx 150 tech-illiterate remote users loose on it, and rolling back if it barfed. I'm not a religious man by nature, but I offered more than a few prayers during my time there. More by sheer luck (or divine intervention :-) than anything else, this actually worked for 3 years with only minor glitches.

You would not believe some of the shortcuts taken by SMEs when it comes to IT. And no, I don't work there any more - flying by the seat of your pants causes uncomfortable chafing after a while :-)

Dear slashdot...

[GoofyBoy]

... I'm special and rules don't apply to me.

How can I convince others of this?

Re:Dear slashdot...

[Anonymous Coward]

Rename yourself Microsoft
Rename yourself Sony
Consider starting a cult
Break the law and don't go to jail
Stop hiding your 6-fingered hand when talking to people ...

Oh wait, you were trying to make fun of the submitter.
You got me stumped there GoofyBoy

Re:Dear slashdot...

[Anonymous Coward]

... I'm special and rules don't apply to me.

How can I convince others of this?

Invent DRM that works.

Re:Dear slashdot...

[Anonymous Coward]

Dear Special:

It helps if you daddy was the president and used to run the CIA.

Re:Dear slashdot...

[sharkey]

Convincing others that you are special?

Try pointing out your tongue marks on the short bus windows.

That's easy.

[mnemonic_]

Just hack the code, Neo.

The keys to the kingdom

[ClickOnThis]

It is best to have one and only one person with root access, even if your users are knowledgeable and honest. This eliminates the chance that two or more users could make changes to the system that, together, compromise its security or stability. Also, if something goes wrong, it's alot easier to know who did it (!) and what needs to be done to fix it.

Re:The keys to the kingdom

[leenks]

Let's hope he never gets sick, eh?

Re:The keys to the kingdom

[ClickOnThis]

Let's hope he never gets sick, eh?

If s/he gets sick or goes on vacation, s/he can always change the password temporarily and designate an administrator pro tempore. Also, it's trivial to break root in an emergency if one has physical access to the machine.

The point is that only one person at any time should have root access.

Re:The keys to the kingdom

[Anonymous Coward]

What if the admin dies in a car crash?

Re:The keys to the kingdom

[ClickOnThis]

What if the admin dies in a car crash?

As I said in the parent posting to yours, it's trivial to break root in an emergency if one has physical access to the machine.

Users are stoopid?

[Gilmoure]

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.

Re:Users are stoopid?

[ChimaeraX]

I work on the server team in a very large environment. Several thousand Solaris, Linux, HP-UX and Windows servers supporting business apps for the core business functions, an engineering environment, one of the largest oracle isntances in the world etc... Just setting the stage that I am not just talking out of my ass here. Our jobs are kept interesting due to the companies history of gobbling up other companies to grow into other areas. The *NIX world has been quite lax about security and with the rapid pace of acquisition, we are constantly inheriting other businesses crap.

In the past we have had a running joke that whenever something went wrong, and they requested we check the logs to find out what happened, it was someone named root who did it...

We recently joined the 90s and implemented LDAP and Sudo and have denied remote root logins. Sure everyone can still su to root, but at least there is a trail now. I totally concur that the people who should know better (DBAs, developers, and app admins mostly) cause the most damage. In a perfect world, no one would have root but a few from the server team to maintain. But it is a long road to get there since we have a few generations of apps that have been implemented and developed with root level permissions and the reach of these apps can be massive.

So I am in favor of restricting access as much as possible within the parameters of the business. At the end of the day, good or bad, the business has to meet its objectives, and all of us in infrastructure exist so that the business can do its job, not vice versa.

How do we survive with so many having the keys to the kingdom? We have strict change control, pristine production environments (as much as possible anyway) and we use data center automation software (cmdb whatever you want to call it) to track changes to all production systems and validate those changes against the approved change controls. We use snapshots and audits to verify what has changed on systems when problems do arise. It gives a really good trail to not only address the issues but also gives us a lot of push back when some dba borks the system and tries to blame the server team or the system itself. We get to say "well user so and so su'ed to root and edited this file and thats when we received the first alert from monitoring that services crashed and these other 2 files changed within 2 minutes of that file edit, etc..." It works wonders. Accountability on the systems is necessary when you have a pretty open environment within the different groups in infrastructure. Now Joe Schmoe user doesnt get anything but user level access, but there are thousands of people in infrastructure who do have root or root equivalent access.

The reality is, all of these folks who do have access are very sharp people and we couldnt possibly manage the servers if the dbas or app admins didnt administer their own servers to a large degree. We just dont have the manpower for the size of our environment. So we rely on them not doing anything dumb, but humans make errors, and such is life in the global enterprise IT world.

Re:Users are stoopid?

[Gilmoure]

Well, certainly, admins (dbas and sys) need some form of root access. And recently, one of our larger problems was caused by someone in IT screwing something up on a server but that's about the only way we have system wide problems anymore. Regular users (not in IT, but admin, research, production, etc.) have been isolated to just their own machines. Sometimes they have trouble with an organizational server they've set up but those are mostly testing machines. Is expected. For regular work apps/db's, we heavily recommend transferring app/business requirement to IT supported server. And then they get no root access, on day-to-day, unsupervised basis. Seems to work. Sure, there's always the impatient ones out there, that demand root to change something themselves, instead of going through channels, but most seem to understand how things are done.

Simply put...

[Solokron]

because "it was an accident" does not cut it when a production server goes down. They getting fired or not because it was logged does not help the fact they hosed a server that needs to be running.

Need more info

[Frohboy]

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.

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 /usr/local/whatever, and tell them how to set up their LD_LIBRARY_PATH to link against it, and they're good to go.

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.)

Re:Need more info

[markrages]

Speaking as a former user of such a university computer, I was *glad* not to have root access on my machine. It removed the burden of system administration, and left me to concentrate on the stuff I was supposed to be working on.

UNIX permissions are designed for just this situation, allowing users to work freely without giving them ability to break the system. Why is the orginal poster trying to circumvent this?

Re:Need more info

[Anonymous Coward]

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[...]

Gah... just noticed I started two sentences in a row with "In fact". This is just like grade 10 public speaking all over again. I suck at composing interesting sentences off the top of my head. (Posting anonymously, since this is useless, and just here to head off people getting funny mods for ridiculing me. Of course, modding this "funny" is totally kosher.)

Re:Need more info

[Anonymous Coward]

When I was at MIT in the mid-nineties, everybody knew the "secret" password to the UNIX boxes on the Athena network. Anyone could get root access on any workstation and modify whatever they wanted.

All the users' home directories were stored on an AFS server with kerberos, so having root on the local machine didn't allow you to do anything to anybody else's files, and nothing to your own files that you couldn't already do.

When the user logged out, the workstation was re-imaged over the network, resetting any changes the previous user made as the superuser.

Re:Don't forget userlimits!

[Morlark]

Ah, that's a classic one. Brilliantly simple. We had a server go down when somebody accidentally typed it into the wrong terminal while trying to test the ulimits on their local machine. Oh, we all had a jolly good laugh about it afterwards of course.

Is your to-do list finite and predictable?

[davidwr]

It's a given that your "must have root to do this" list is finite, but is it "smallish" and something that can be predicted in advance?

I ask because if you only need to do a few dozen things over and over again, the admins could configure the system so you could do your work without root.

On the other hand, if your "must be root" tasks are new every day then you might as well be a system administrator. Just be sure you keep the real sysadmins up to date with any changes you make. Change control is important you know.

Root Access?

[DA-MAN]

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.

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 ,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.

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.

Makes no sense...

[boner]

(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....

Re:Makes no sense...

[Large Green Mallard]

I am glad you did point out at the beginning that you work for Sun, since it does explain your point of view on clustering :) Otherwise it would look entirely crazy.

Beowulf can mean cheap hardware, Sun doesn't. Government doesn't always need secure. He doesn't say what part of the government.. it might be the department of the interior doing climate modelling or something. Trusted/Secure Solaris adds huge amount of overheads to installing and configuring and using a system that they just might not need. Sure, the original poster's view on system administration is somewhat unconventional, but it does seem like they have on-site staff who are more than capable of putting him back in his padded box.

In my opinion you have forced your customer to make a move on questionable grounds .. 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.

Re:Makes no sense...

[Antique Geekmeister]

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.

Re:Makes no sense...

[Anonymous Coward]

You should check out modern versions of Solaris. Most of these issues have been dealt with either in Solaris 10 or as part of the OpenSolaris project. Seriously. Solaris 8 is 6 or so years old now.

Re:Makes no sense...

[Karma Farmer]

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

WTF? He was talking about a production cluster. The only production machine that ever has a compiler is the one in the corner named "build". And, since developers don't get a logon to build in any decent IT shop...

Re:Makes no sense...

[boner]

Beowulf can mean cheap hardware. Cheap hardware is not were most of the money is spent.
(You imply that Sun doesn't make cheap hardware, I state that you haven't brought yourself up to speed with Sun's current offering. The Opteron servers with Infiniband interconnects make quite a nice clustered environment.)

Programmer productivity is were the money is. Getting a program to work for a clustered environment requires a lot of skill. Often the code is hand-tuned to work over the particular configuration of a cluster. What we lack from the original poster is information on what environment the customer currently runs on and what their needs are.
My post is merely pointing out that it is an oft perpetuated myth that cheaper hardware equals more bang for the buck. It doesn't, the additional cost in developer time spent to make those applications suitable for a new cluster is usually equal or greater than the cost savings.

There are many issues related to programming for- and executing in- clusters. Only when you are using really large clusters on programs that are well understood does it make sense to make transitions (as in the ASCI red and blue) to benefit from new hardware. Usually program improvement is the best way to improve performance.

You might consider Sun a losing company, I don't have that feeling. Sun certainly has it warts and we haven't done the best job in market perception. However, do you really want a world without Sun? Sun is still a powerhouse of innovation, we are open source friendly and in our core we are still geeks that enjoy technology.

Re:Makes no sense...

[swordgeek]

Fascinating. I can't imagine why you'd spend so much time beating a bunch of Sun's into pretending they're all Linux systems.

Re:Makes no sense...

[Antique Geekmeister]

Of course they need a local compiler! Matlab uses one for building local OS dependent bits of tools, or you can use one to build dozens of kernels or X distributions simultaneously, or to build up 50 slightly different versions of software in all its permutations for regression testing.

The compilation itself is one of the most time-consuming parts of its operation in many environments. Without it, you're single threading a core operation onto that build machine, and made that one machine with the compiler absolutely critical to what should be a set of 20 or 100 or 500 identical machines. Depending on what you're doing, the compiler is the whole point of the cluster, matched only by the source control in importance.

Re:Makes no sense...

[trollogic]

"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.
"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 .. can you say the same for Linux ?
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 .. 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.
That said again, have you looked into Solaris 10 RBAC ? (Role Based Access Control) .. And as the parent poster mentioned, if you are running MPI jobs, you do not need to be a root user.
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 .. And yes, I build supercomputers for a living.

Re:Makes no sense...

[Anonymous Coward]

Even if the goal was to move to Linux, that doesn't rule out sun hardware. I think you have a point about compiler differences. I don't think admins realize that gcc on two different operating systems can still act quite differently. I'm a cs major (senior). Last semester, I wrote a Common LISP interpreter in C++ on my iBook using gcc 4.0. It worked fine on OSX, but moving to linux caused it to randomly fail. On sun hardware (and solaris 9), the program crashed immediately. Do to other factors, I passed the assignment but i think it shows that other programming environments can be quite different. This is quite a simple example, but imagine the complexity of a cluster in comparison to a computer science students personal experience.

That being said, I think its rediculous that so many people blindly switch operating systems. Linux is in right now and i think a lot of people are running it that have no business doing so. I overheard a conversation at the local pizza place between a guy and his girlfriend. He was trying to convince her to switch to linux like he "runs at work". He actually said that linux boxes could not talk to windows machines! Samba anyone? I ran linux when it was still kewl to do so prior to the .com crash. You know back when the file system would die with a simple power failure. Its now a mature system, but its just a reinvention of system v and bsd. If you chose linux after researching all the options, couting the cost to switch in programming, administration and other factors and its a good idea, then do it. If you are doing it because it gets you geek points, forget it. Windows NT4 was in for awhile too.. look how that turned out. I think ISPs are a good metric. They tend to be behind the curve on operating systems. They adopted solaris and sco then *bsd (especially freebsd), then linux and the younger ones tried windows nt 4 or even win2k. Are you going to recommend windows next? You know they have a super computer version coming out soon right? That will be nifty.. it takes a supercomputer to run the start button.

Maybe it wasn't right for this sun employee to post, but you have to give him credit for stating his potential bias and i think he has a point.

I'm not a sun employee, i work at a university as a mac os x admin. I used to be a windows, linux, solaris and freebsd admin. (most of which at an isp)

As for sun, they are trying right now. Opening up solaris was a good start. I'm concerned about java's future though. I wish sun would embrace their BSD roots a bit more. I don't think people give many companies enough credit including sun, apple, hp and even sgi. All four have contributed innovative ideas, technologies, libraries, etc.

Re:Makes no sense...

[Mr. Hankey]

A short time ago, we had attempted to purchase a set of systems from Sun. We have to do a competitive analysis on all purchases due to various regulations, so we did a comparison between a rackmount node from one unnamed vendor and Sun's newest low end Opteron rack mount systems. We even brought in one of our Sun reps to attempt to get the prices closer. In the end, Sun was offering us a system that was $1500 more expensive per box, used one single core opteron, and was otherwise identical to the systems from the other vendor. Unfortunately, the other vendor was packaging two dual core opterons. We were forced to give the other vendor the hardware contract. This is no way to compete when a customer is expanding an existing cluster.

Remember, Infiniband works on other vendor's hardware as well. If Sun doesn't make themselves relevant, it isn't my job to make them so.

Re:Makes no sense...

[JabrTheHut]

Just a small point: RBAC came in with Solaris 8 or 9. Solaris 10's security contribution is Process Priviledges (or however the heck you spell it). Much more fine-grained control compared to RBAC, and without selinux's headaches.

Re:Makes no sense...

[JabrTheHut]

Maybe I'm approaching this from the wrong angle, but cheap hardware and programmer productivity are irrelevant. What is relevant is keeping the cluster up and getting it to finish. The Linux clusters I'm seeing replacing Solaris processing boxes tend to be almost as expensive, simply because they're much larger. They have to have enough processing power to finish everything even if two or three nodes crash or fail. Considering how much less reliable the hardware and the OS are (no, this is not a troll or flamebait, this is years of experience talking), this happens surprisingly often. Most days the clusters finish hours ahead of Sun. The extra nodes ensure that when a bad day happens, they don't finish too late in the day.

Re:Makes no sense...

[Anonymous Coward]

Yeah, but they still suck. Hey kid, get a real machine :) - Get AIX at least, or preferably a Z series.

Re:Makes no sense...

[theProf]

Agreed. No need for root. Root on developers workstations is also very poor. The main case would be for device driver development. Not for modelling. This just looks like poor administration to me.

Solaris will run on whitebox x86 hardware - I did this for years. It's just like linux. You need to mug up on device compatibility. You can go to blastwave & friends if you want another toolset. Not a problem, nosireee. Just the RPM generation.

I don't think these lads need Trusted Solaris, but they probably do need to make use of Role Based Access Control.

As Mr Boner indicates, Sun do have a good story. They have cheap gear, know their kit from the chips up to the shell.

The costs of migration may look cheap, but if you are throwing away experience and a developed environment, then the those costs ought to have been factored into the 'persuasion'. They are big numbers. It can yeake admin-years to re-establish stability.

It's very sad to see a original poster asking such basic questions, especially if he is driving the technical direction of an organisation.

Note: my first linux installation was a slackware with 0.97. My first solaris was 3.0.6. Anyone remember Whitechapel ?

Re:Makes no sense...

[Anonymous Coward]

Yeah, and AIX sucks worse then Windows XP.
Why not move to that!

When you're on the best os in the world( Solaris )
  you've got to deal with all the Wana'be Os's putting in their two cents.

It's tuff being the best.

Re:Makes no sense...

[Antique Geekmeister]

I think you missed the point. The tools and issues with Sun tools, which I described in detail, are not fixed by making the machines Linux. They're fixed by making the machines far more GNU or other Free Source based. Sun has repeatedly pursued proprietary, closed technologies to achieve goals and seen them discarded by most developers and engineers in favor of the more supportable, more robust, and more cross-platform and therefore more familiar tools of the GNU or other open-source license world.

Linux is based on that world, but most of that world is the open source in the operating system, not Linus's kernel. One result is that in numerous Sun shops, you see people stapling in important open source tools and seeing them ignored by Sun, despite their clear usefulness, and the result is a lot of support pain trying to wedge together the different open-source components to make a complete system. How many Sun systems have you had to build "top" for?

The other result is that if you want a fast, capable, and easily configured NIS server, you don't use Sun. You use Linux, or you use a Sun over your protests and staple Webmin on top of it to give you a decent interface, because the defaults of Webmin and of the Linux world for NIS configuration are so much saner. If you want files shared with Windows boxes, you don't use that horrible old PC-NFS tool or buy one of the commercial Sun-only SMB server packages, you install Samba and you're done. If you want cheap backup and tape management from a Sun, you don't lay out many thousands of dollars for a Veritas license and client licenses, you slap in Amanda and maybe an array of external disk for staging the backup, and you're done.

If you need individual Sun servers for overwhelmingly large applications, like an Oracle database with high load, I'd recommend them. They're a great replacement at lower cost than the old IBM big-iron. But for cluster computation? There's no point to buying Suns.

Re:Makes no sense...

[Net_Fish]

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

Re:Makes no sense...

[swordgeek]

Well, I didn't miss your point, although perhaps I didn't make myself clear.

You're taking Sun systems and gluing a big pile of open source stuff onto it, until Solaris looks like Some bizarre flavour of Linux. Call it GNU/solaris.

Some of what you say is true, or at least has been in the past. On the other hand, much of it is either (a) long-since fixed, or (b) the fault of poor coders. Solaris comes with SAMBA (PC-NFS hasn't been available for a few years now), Solaris comes with prstat, which is a much improved version of top, and so forth. Mentioning Amanda makes no sense to me, because it doesn't come with Solaris OR most Linux distros I've played with, but IS readily available for both. Furthermore, it's not replacing any proprietary (and unused) part of Solaris. At any rate, Amanda is nice if you want cheap backup and tape management on either platform. If you want scaleable enterprise-level backup and tape management, you spend the money to buy Netbackup--on either platform!

Running a Linux NIS server is just odd. Running a Linux NIS server because it has a pretty interface to manage the single easiest naming system invented is just sad.

In your previous post, you mentioned some of the things you don't like about Solaris (built-in tar, libraries that don't behave), which highlights where one of the key problems lies. There are two types of standards, of course: Formal and de facto. GNU software has a BAD habit of extending the formal standards, which leads to people relying on all of the extented behaviour. How many programs out there are so poorly written that they can't be compiled with anything except gcc and gmake? Too damned many! A similar problem is man pages that don't render in standard troff, but require groff instead. Lazy, poor, third-rate programming is the problem, not "proprietary tools."
If these DEVELOPER problems were fixed, then most of the platform-dependent problems would go away.

At any rate, replacing Sun Cluster with Beowulf is still an odd decision, because the two products are designed for different purposes. The core purpose of Sun Cluster is high availability, whereas Beowulf is compute farming. Moving an HA environment to beowulf is risky and probably not well-thought out. Putting a compute farm on Sun Cluster is (likely to be) equally badly planned.

Re:Makes no sense...

[Anonymous Coward]

Have you used Solaris 10? Because Solaris 10 ships with something like 4 CDs of GNU stuff. How about Solaris 9, even? Hell, even Solaris 8 borrows heavily from free software.

Solaris doesn't have "standard X libraries"? Which standard X library does it lack? libX11? libXt? Ohhhh, you meant Gtk+! I'm sorry, I thought you were talking about standard X libraries. Well, Solaris 10 ships with Gtk+, if you really want to know.

The other post is absolutely right in that you're just complaining that Solaris isn't Linux, or the "difficulty" of installing GCC. Any Solaris admin will tell you that these issues are trivial to nonexistent.

Re:Makes no sense...

[Antique Geekmeister]

You make more sense to me now. I really think that you've not tried dealing with the vagaries of Sun's versions of tools in comparison to the open source tools: that Sun tar vs. GNU tar comparison is a tiny tip of the iceberg of Sun practices that are dangerous and should have been discarded 10 years ago.

But I've seen numerous systems where the flaws of Solaris commercial C was revealed in comparison to gcc. And people use gcc and gmake for development because they can't afford whatever specific compilers Sun sells to test with. If they want customers to be able to use the products they need, they can embrace the newer de facto standards or be left behind.

Manpages, I agree with you about. People get way too cute with those, and often can't be bothered to write them, and when they do tend to include multi-language oddnesses that break them in standard tools. But why should they? They're a big problem. But the Sun versions are way, way out of data: the GNU versions of tools nroff, make, and tar are in fact the standards in the developer world, and Sun needs to suck it up and move forward with those.

The Sun Cluster setup I saw last was, in fact, some foolish mortal doing a not well thought out request. But I've actually seen what the clients referred to as a Beowulf Cluster managed as something like a high availability farm: it was weird, but it worked.

Not On Your Life

[highwaytohell]

Why you ask? Because i find end users in particular believe their capabilities are such that they could re-write the whole OS, even though they have trouble typing things in a word processor. That, and i dont trust them, people are inquisitive, they like to search around, and inevitably, manage to find a way to screw things up. Giving that sort of access is a bad idea, let alone putting it into practice. That just opens up a Pandora's box of late nights trying to fix the fsck'd system.

Permitted with a clear duty to log actions

[originalhack]

I have always had this ability (in several of the largest companies in the US) but I have always started the conversation with an acknowledgment that the sysadmins are ultimately responsible for the network. Then, we focus on what functions I may need to do, how I avoid causing a problem beyond my own work, and how we can establish a regimen where I report what I have touched and where they are able to monitor to ensure that I have do only that.

This has never been a problem. Then again, they already know, prior to that, that they would be in bigger trouble if I were not trustworthy. I offer them more controls than they would have insisted on and this gets me more latitude than they normally would have offerred.

Give them their own systems

[Anonymous Coward]

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.

Doesn't that defeat the point?

[NitsujTPU]

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.

Re: Got Root?

[hedrick]

I work at a University, so we may not be close to your environment to matter. But I would distinguish between production and research systems. I wouldn't give anyone but professional sysadmins anything close to root on systems like mail servers or multiuser systems. But unless you're working with sensitive data, on research systems things are more flexible. A lot depends upon the sophistication of the people involved as well as the actual environment. I'd be more inclined to give out root on a machine with one or two users and I'd be more inclined to give it to somewhat who had sysadmin experience. On a machine shared by a small research group, if I could find one person with reasonable experience, I might try to coopt him into the sysadmin group. That way there's somebody near the users who can solve their problems.

These days security is an issue. But with a compute cluster I'll bet I could come up with a setup where moderate errors wouldn't compromise the rest of the network. A compute cluster is easier because people won't be running browsers on it or reading their email there. That eliminates most of the user-caused problems. So at that point a tight firewall may be enough. On a small research machine used by one research project you're not really trying to protect users from each other. So many of the traditional concerns about protection don't apply.

ACLs?

[harlows_monkeys]

If you use a filesystem and kernel that supports ACLs, users can do everything they should need in almost all circumstances.

There are only a couple of situations I've run into where I've needed more, such as applications that need to bind to a priviledged port, or where I've needed to run a cron job that needed more than 1024 file descriptors and so had to make it setuid root. (Setting the number of file descriptors up for a user via /etc/security/limits.conf doesn't apply to that user's cron jobs).

Switched from Solaris to Linux? Dumb move!

[Anonymous Coward]

With Solaris 10 you get so much fine-control over security that you can kick sudo out of the window and use Solaris's built-in tools. Dude, your move to Linux is going to bite you in the arse!

Re:Switched from Solaris to Linux? Dumb move!

[ryanov]

Same with SELinux though really, right?

Re:Switched from Solaris to Linux? Dumb move!

[Anonymous Coward]

Yeah, but what's the point. Solaris is now "Open".

This is where you have multiple environments.

[Anonymous Coward]

A sandbox, where the developer can play to his heart's content, doing whatever he wants. He breaks it? He fixes it, or it gets nuked and reinstalled.

A test environment, where every change is logged and monitored. Nothing goes through without being authorised and signed off. The sysadmin is informed of every change, and is allowed to nix a change, for whatever reason; if the developer insists, the sysadmin and the developer sit down to talk about what is being done and why, and why the sysadmin is balking.

A production environment, where every change is logged and monitored. Nothing goes through without having been through test first, nor without the change actually having been tested to a fare thee well.

Allowing any random person the right to chmod, cp, mv, or whatever any files as root is a recipe for massive instability and security problems. Don't do it, unless it's in a sandbox.

Why would you move from Sun Solaris to Linux?

[hutchike]

Solaris seems to be faster than Linux these days, and runs on swanky new Sun Fire T2000 servers. Whether you run Linux or Solaris, file permissions are always an issue. Get used to it.

In defense of sudo

[Anonymous Coward]

I'm a Unix Sysadmin (HP-UX, AIX, Tru64, Solaris) who works with a team of Unix admins to handle user requests. I've seen several replies about "not even with sudo access to " but they aren't accurate.

Sudo can be set up to allow a restricted set of commands. Yes it's a pain to give them specific permission to chmod specific directories. Yes it's a pain to set sudo up so that it not only gives fine grained permissions, but also has fine grained denials. This is the power of sudo, and if it's set up properly can be very helpful in reducing some of the work load the admins would be asked to do in a safe manner. Throw logging into the mix, and you can prove WHO ran the command that broke their toy, which is important when someone wants to point fingers. Sudo isn't perfect, and the users shouldn't be given rights to do certain things, but for basic tasks (allow a web developer to reboot the web server on the development box, for instance) it's a blessing.

Chroot them...

[Yaa 101]

And only give them the tools they really need to develop, test and debug their programs.

Secure != root

[Anonymous Coward]

Bottom line is only one single group/user should have full access permissions. Keeping you sandbox is both a blessing and curse. Truat me when I say that the stress level is Much Less when you have only user level access permissions. Enjoy your day and thank the sys. admin when you see him.

No more Sun?

[St. Arbirix]

What's wrong with keeping Sun and running Linux on that hardware?

Another question: What's wrong with Solaris?

Re:No more Sun?

[Karma Farmer]

Another question: What's wrong with Solaris?

Read a few "Ask Slashdot" questions, and you'll understand. Ask Slashdot can almost always be summed up:

"I've been running linux on the computer in my bedroom for a long time, so obviously I'm incredibly 144t. I just got hired as a summer intern doing tape backups at the local brewery, and I built a beowulf cluster out of old 486sx's I found in the dumpster. How do I convince my boss that we should restructure the company's entire infrastructure around open source software? Also, does anyone know an open source program for running a brewery?"

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.

Developers need more discipline

[alee]

I've been both a developer and an administrator.

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 /usr. root access as we know it is a luxury that should be reserved for true administrative duties, unless absolutely positively necessary.

Re:Developers need more discipline

[Sycraft-fu]

It also leads to shitty apps that don't play nice in multi-user environments. I particularly run in to this with Windows apps since Windows has the "amdin by default" thing going on. Now Windows is designed such that you never need admin to make your app work. You may need it to install your app, but anything that your app needs access to do, it can get during install. It's also designed so each user has a seperate space for storing temp files, config files, data files, etc. This is all well documented, and easy to work with.

However, since most devs work on their box as admin all the time, as indeed do most users, you get plenty of really retarded things that happen that wouldn't if they tested it as a limited user. For example there's a program we use that requires all users to have modify permissions to its directory. Why? Well that's where it puts its config and temp files. Rather than put them in the current user's application data directory it stores them there, and thus fails to work without those permissions. Of course that means that any user can hose the program for all other users as well. The authors don't seem to see a problem with this.

For development, I generally think that not only should you not need root, you should delibrately not use it. I realise there are cases where you need it (like writing a driver) but for a user app, if you are using root it probably means you are doing something wrong.

I think you are correct in that many root/admin demands just come from laziness. People want to use bad coding practises and can't do so as a user. Rather than figure out the right way to do it, they just whine.

The other extremely common one is to install software they shouldn't. We get requests for admin on Windows desktops all the time. Unfortunately, that's something they can get (unlike root). Well, invariably we see the system some time later, riddled with spyware. If there aren't apps on there that shouldn't be, there's traces of them having been uninstalled. The reason they wanted admin wasn't because their work required it, but because they knew we'd say no to app installs.

That annoys me even more. This isn't you personal machine. You want to install all sorts of shit, do it on your own box. Computers at work are for that: work. Sure, we'll be happy to install things like Winamp, IM clients, or other non-work related programs, that help the day go by, but this isn't the place for P2P apps, games, etc. Do that on your own computer on your own time, and don't ask us to fix it if you break it.

accountability and change control

[Yonder Way]

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.

Hell yes!

[Anonymous Coward]

I liked it so much, I pwn3d the company!

Users != Root on servers, not workstations

[DonGar]

One variation that I've seen work well is to allow people full access to their own workstations, but not on servers (or clusters in your case).

This limits the types of access people can have on the heavy server machines, but lets them install apps or do whatever they need locally, including installing a different OS or OS variation based on need or preference.

Of course, the more people 'adjust' their workstations the less support you can afford to give them. You also have to be very careful about how much servers trust any information from workstations (NFS can be very tricky to get right), and have to more draconian with your firewalling policies.

Security versus usability is always a balancing act. It just depends on which balance is right for your environment.

Re:Users != Root on servers, not workstations

[Halfbaked Plan]

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.

Re:Users != Root on servers, not workstations

[Profane MuthaFucka]

Take a lesson from this guy - he's smarter than he looks. When you find a security hole like this, do NOT report it unless you can do it anonymously. If you can't report it anonymously, then just sit on the knowlege until the end of time. This is your job, your life, and your paycheck. We've all read the stories about how the person who reports a security hole gets criminally prosecuted for "hacking". You might be a smart person, but everyone around you is a blathering moron. That is a FACT. That blathering moron isn't going to say "thanks for pointing out this embarassing security hole that my ass was hanging out of." The blathering moron is going to try to cover his ass by blaming somebody else, and the easiest somebody is YOU. That way he takes care of the problem and gets brownie points for uncovering a dangerous "hacker" within the company.

Next thing you know you're getting arrested by a nice FBI agent named Bob, and then getting cornholed for days in the local jail waiting for a judge to set bail. It's not worth it.

Re:Users != Root on servers, not workstations

[mcrbids]

funny thing, that security stuff.

Years ago I ran a network to transfer messages, much like Email. Then, it was typical to relay some 10,000 messages per week. I worked in a regional office. We're talking DOS 3.2 and Banyan VINES days, 286 systems and token ring networks, when 19200 bps was considered "fast", and the best modems available where 9600 bps.

Well, being curious and all, I read the manuals, starting with MS-DOS. Got a working knowledge, used batch files to tweak certain, commonly run commands, and improving performance by some 50% without any necessary hardware expenditures. (partly by creating a RAM drive in the upper 384k and loading commonly used commands there for sped) I was feeling pretty good about things.

Then, I started reading up on the NOS, Banyan VINES. I did a network scan, and found another system. It was call "Itl". I logged into it, and started poking around, just curious as to what it was I was looking at. Turns out I was logged into the International Computer of the telecommunications network!

I logged out immediately, and said nothing for a while. But then, doing some "file cleanup", on my server, I got confused and nuked some stuff I shouldn'ta. Remembering my access to the International System, (which was largely an exact duplicate of my regional network server) I logged into it, copied over the files, and then was suspended from work for an entire WEEK while they grilled me about what I saw, what I did, and then yelled at me.

They finally realized I wasn't malicious, that I made a mistake (that I wouldn't make again, EVER) and that I fixed it without loss to the organization. I was eventually allowed back to work. Sure as hell shook me up, though, and I guess I wasn't the only one..

Re:Users != Root on servers, not workstations

[nathanh]

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

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.

Re:Users != Root on servers, not workstations

[Anonymous Coward]

No. Tell me its not so. UNIX has a security flaw? How can this be possible? Microsoft is nowhere in sight. Hmmm. Maybe, just maybe the problem is that operating systems and networks of operating systems in general are simply too complex to make truly secure against any attack. That is, if you are going to use them.

If you want a secure system. Turn it off, unplug it from the network, disassemble it into its component parts, and destroy the memory and hard disk. THAT is a secure system. Anything else will have security holes. Its not the evil ones at Microsoft who cause the holes. Its the nature of the beast combined with the desire to be able to do something with it.

Re:Users != Root on servers, not workstations

[cortana]

Does this not completly break the security of NFS? Though I suppose, you would also have to somehow prevent an attacker from, eg, plugging in a laptop too.

Re:Users != Root on servers, not workstations

[allenw]

NFS (as shipped by Sun) has supported Kerberos for NFS security for quite some time. Unfortunately, not many other vendors or even open source operating systems implemented this. Luckily, this is now required to for full NFSv4 compliance.

Don't blame NFS (or Sun) for poor implementations.

Re:Users != Root on servers, not workstations

[ThinkingInBinary]

This is fucking depressing. You're basically right. Never mind Score:3, Funny, that ought to be Score:5, Insightful.

Living in a day and age where helping people out with security problems makes you a "hacker" and a "criminal" is really shitty. I'm happy that the tech people at my school are friendly and happy to discuss security issues. (It helps when it's a consultant, and not their own jobs that are at stake :-b)

Re:Users != Root on servers, not workstations

[fluffy99]

Congratulations, you've discovered the major security hole in NFS - if the client name/ip is allowed to connect then NFS blindly trusts the UID presented by the client. This is still a major problem in *nix as people forget to disallow the root uid, which means anyone who controls a trusted box also now controls your box.

Re:Users != Root on servers, not workstations

[jbolden]

That's not an unreasonable policy. What it is is poor implementation of a low security model. Its basically the old rsh/rlogin... model where server A trusts server B and so anyone with privs on A gets the same privs on B. Now the question is why was your desktop given that level of trust to important information that needed to be kept secure? There are a zillion holes i the rsh model if one of the trusted servers can't really be trusted.

chmod

[xx_toran_xx]

If you allow users to chmod, a savvy (enough) user could change permissions on the right stuff (such as the sudoers file) and give himself more access than you may want him to have.

just a thought

Don't install the software as root.

[digirus]

A quote from a text book of mine that I think may help: Some users with unix experience, and particularly those experienced in the linux flavor, may find this caution to be peculiar, in that a conciderable amount of third party software seems to end up installed in privileged system directories these days, as so they might have gotten used to needing to be root to do simple installs. This is the worng way to do things, and fortunately it's a rare unix application that will force you to do things in a poorly thought out fashion if you don't want to. Almost all non-OS-vendor software should be installed and owned by a non-root user. Even vendor supplied copies of third party applications (such as the Apache web server) are best owned and installed by non-root users. This model makes life a slight bit more difficult than just having root own everything, but the benefits far outweight the minor inconveniences. If you conscientiously make certain that everything that's not distinctly part of the OS is owned by a nonprivileged user, you can allow nonprivileged users to modify and maintain those parts of the system with no fear that they are going to do damage to the OS itself. The machine is more secure, the workload of managing software can be distributed, and those users who need to modify configurations (such as the web server settings) can do so without having to annoy root, or run the risk of compromising the system by a careless keystroke while operating as root. Implementing this model will take a small additional amount of effort on your part. You won't be able to follow people's simple-minded instructions to "sudo make install" bits of software. But your machine will be better managed and more secure, and you'll be helping to keep mushy-headed thinking from taking hold of the *NIX platform, if you just take the time to follow these suggestions and set up a nonprivileged software account to own and install the majority of your third party software.

Re:Don't install the software as root.

[Onan]

Hm. While the intent is good, I'm afraid that I have to take issue with this methodology. A couple of reasons:

• Server software should certainly run as not-root. But it also needs to run as a different user than the one that owns its binaries and config files. (Or, indeed, anything on the filesystem other than the very specific files it needs to handle for its normal operation. Even logfiles should be opened first and then have privileges dropped.)
• All package management systems of which I'm aware tend to operate on a per-system basis, not a per-user basis. And, all else being equal, package management is a great boon to system consistency.
• The idea of allowing non-privileged users to admin applications can be a tricky one. For example, if the machine in question is a mail relay, and a "non-privileged" user has the ability to break that service, or accidentally turn it into a spam-friendly open relay, or expose all users' mail... that's not substantially less bad than the set of things that root could do. I'm not saying that there's never a place for application admins, but when the application is the machine's only raison d'être, separating admin access tends to be less meaningful.

Change Management

[oc-beta]

Is very important in high availability environments. I find that a lot of times, due to lack of communication, I will change something on a server, and another admin will come along. "Who the heck did this?" And change it back. So I end up spending a good portion of my day doing things a few times. Now, I would implement change management if it were a high availability system. Instead it is just our dev network.

Why the ell not.

[Anonymous Coward]

The summary mentions giving users access to commands like chmod, cp etc.

Of course you would give them access to these commands - just in their own little home areas, other areas would be restricted by root permissions.

I see nothing wrong with doing such. If they want to do system level things let them play on a play box.

This is not based on any reality

[Anonymous Coward]

This policy keeps IT people employeed, builds IT's fiefdom.

Effects on 'customers' and their productivity is irrelevant, doesn't even cross anyone's minds. These are bureaucracies you are dealing with. Think reptile vs advanced mammal when discussing the differences between bureaucracies and even horrible profit-driven organizations.

I worked for the State of California on a contract about 20 years ago. At that time, the PC was just getting off the ground, but PC-users were forbidden to do anything that could be construed as programming, e.g. spreadsheets and databases. They had "computer police" who came around and inspected computers. Woe unto you if you had forbidden applications. Of course, a lot of people therefore worked from home, did all their databases and spreadsheet work there.

Maybe that policy has changed, but if so, it wasn't because IT decided it was a wise way to enhance the state's productivity. More likely, everyone went along with IT because it increased their budgets.

Lew

root should stick with IT

[tolldog]

If a system is set up correctly, developers should not need root privs. If there are sitiuations to the contrary, then they show a bigger problem with how things are structured or problems with the IT group.

Only IT should be able to modify the base install of a system. This includes common libraries, binaries, directories and other things that are on the system when it is rolled out.

Need to install new commands in a common tree? Have some other directory that is added to a common path that privelaged developers are able to install in.

Need to change file permissions? The only time I have seen this needed was log files that got owned by root after rotation. A better thing would be to make the rotation script give files correct permissions to begin with. A user should not need to change permissions on local files.

Need to install new software? If this is a real server and there is no tracked, established procedure for software being upgraded/installed/removed or altered in some way without IT involvement, there are more serious problems with the structure than the software change. There should always be a procedure that is followed with software changes, that should either be done by or with an IT person.

Servers should rarely be touched. Even desktops should rarely change if you expect some level of support from IT. If the IT group is not giving you the level of support for you to easily do what you need to do, the problem is not the lack of sudo, the problem is the lack of procedures and tracking and all the messy parts of IT that go beyond the root priveledges.

I have had to work on both sides of the sudo/root issue before, and I have seen places where giving root to the wrong person has caused more problems than it has solved. In jobs where I haven't had root, but needed it, there were bigger problems about how software was rolled out and administered. My need for root was a band-aid, quick solution to work around the bigger problem.

I am a firm believer that NFS filesystems should not be mountable without root squash except on a trusted server. If security in your company is important enough to have multiple users and user groups, it is important enough to limit root to those that have to deal with that type of work on a day to day basis.

I can see possibly allowing for one developer in a department to have some level of sudo but only if that person in an IT type support role for the department. (This does not mean somebody who also does IT work because dealing with the IT department is slow and cumbersome.)

sudo to a shell

[vivarin]

We have a special shell for some users that requires they enter what they're doing. They basically do "sudo bashforroot" and have to type in "installing foobarnator" and then they get a root prompt.

Whoah

[gringer]

Imagine a Beowulf cluster of those...

Oh, wait a second. You already have.

Why do they need root?

[ChaosDiscord]

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.

Re:Why do they need root?

[bob2cam]

"But this is Unix. It's a rare piece of software..."
Unix has software? I'll be damned. I wonder how all this would work with millions of commercial applications available?

Re:Why do they need root?

[Anonymous Coward]

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.

Myth. In a business environment, there are very few programs that require administrator to run.

Re:Why do they need root?

[naelurec]

Myth. In a business environment, there are very few programs that require administrator to run.

I maintain the networks for quite a few businesses and while this is true for larger, current apps (ie Office 2003), there are still many apps that prompt for administrator access, run but abnormally fail (ie trying to write to a folder w/o proper permissions or to a system level registry key) or in a worse-case, continue running but don't run correctly (bad error handling) thus causing data corruption/loss.

Even things like working with msconfig will prompt a regular user with that stupid "something was changed in msconfig.. blah blah blah" message but even when the user clicks not to see that message again, it still appears due to the fact that is (for some stupid reason) a system reg key.. needless to say, if an admin makes a change with msconfig, the user should not see a dialog..

Same thing goes for fonts .. regular users can't install their own fonts w/o having to manually (afaik) adjusting the security setting in the registry (PITA).

Needless to say, while these issues can most of the time be traced back to file system permissions or incorrect registry use, the fact is that companies are STILL NOT testing using regular user accounts.. I report these issues to companies when I locate them, tell them how I solved the issue but even when new releases come out, the issue still exists .. blech. Hopefully the defaults change in Vista so these programs are BROKE and the companies will finally fix and test their software correctly.

Strangely, I don't run into these issues on my *nix systems.. go figure.

Re:Why do they need root?

[johnw]

"I development clustering software"!?!

I hope that was a typo and not another example of demented verbing.

Re:Why do they need root?

[temojen]

Even many admin-only windows apps can be run as non-admin if you carefully track down and change the ACLs on the files it needs. Most commonly these are data files naively stored in the "PROGRAM FILES\programname" directory rather than "CURRENT USER\Documents and Settings\programname".

Most just say no.

[Liam Slider]

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.

I'm a developer...

[stevens]

...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.

Re:I'm a developer...

[ivan256]

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...

Re:I'm a developer...

[Karma Farmer]

Can we somehow mod the above comment to +6, and close the thread?

There's really nothing else that needs to be said.

Re:I'm a developer...

[Anonymous Coward]

There are lots of types of machines and lots of levels of security. The important stuff, like the email server(s), the fileserver(s), trouble ticket systems, oracle, or whatever custom apps you have that multiple users need and really depend on, these servers need to be locked down totally. Users should only have user accounts that allow them access to the particular service the server provides.

Then for user desktops, lots of people only need specific things for their job. They should get locked down boxes, its nice to be able to install whatever you want, but allowing everybody to change whatever they want is asking for trouble. They only should be able use an email program, launch a web-browser (maybe), and whatever custom apps they use. Whether its a laptop or cube desktop lock it down. Now some people really need more freedom on their desktop, high level admins, high level devolopers, They probably can make a case for root on their laptop or desktop, but think before doing it.

For developers, giving them their own test machine is a good idea, but then if you don't manage it then it can be a source of virus/worms on your network. So you should try to manage their test boxes if you can. If they're a web-developer, you can install apache as a user space app, let them run it on 8080, etc. Lots of problems can be solved with users and groups if you think about them instead of giving up root everytime someone asks. But in reality, lots of these users are reinstalling the box all the time (after they hose it up, or change from one kind of test machine to a different one). You should have a security policy, make these users aware of how they need to update their systems. Embarassment is a great tool, if someone leaves a box unpatched, and its now a worm-server causing problems throughout the company, make sure to name names. Make them feel like a moron, let other users know their work was destroied or slowed down by that asshole's foolishness.

Users pretty much never need anykind of admin access to an oracle server or an email server, but for custom apps, etc there is a class of really important, business critical boxes that lots of people have their hands in, and need admin level access. If you can you should restrict access, make changes go through a NOC or some administrator. But for my company we make systems that the public accesses as users, the systems needs to talk to our customers hosts, and our customers need certain levels of access for reports, logs, etc. We almost always keep the customers out. But sometimes their money makes us violate our policies. We wrote the runtime, we, our customer or a 3rd party wrote the specific the application/script. So we have OS patches, our environment patches, and application patches. And also we have 3rd party software for certain functions. So no one person can really understand everything going on for any one box. Multiply that by having lots of boxes, and lots of diferent customers and applications, hosts, etc, it can be a mess.

So inside our company developers, high-level engineers, techs, NOC people, even some managers have full access. And they do things. They break things. They make us look bad. But the only thing you can do in this area is to have redundancy, so if someone breaks something, other unchanged servers remain working. Have good alarm management software, have automated test calls, web transactions, test host accesses, etc to detect failures. When someone makes a change, make sure they have to test it afterwards. Limiting access is the best thing to do, but it can be very hard, expensive and time-consuming to do so.

Re:I'm a developer...

[kyncani]

I'm a developer too, and i do NOT want root access either. In fact, on a dev vms station, i had to ask a dev account with LESS privileges so that i could test things that did not require any specific environment. This is a question of security. The less privileges i have, the better the chance of all stations to be up and running when I need them .. and the better I sleep :)

Re:I'm a developer...

[greyguppy]

I am a student, and occasionally need to ask root to do things, but my level of access at uni is I feel appropriate for any linux dev, namely user with no sudo whatsoever, but root will run commands I need run assuming they are reasonable, necessary, and authorised by my prof.

The last time I needed root to do something was when we prepared a group presentation then one of the group had his umask wrong, forgot to chmod, and failed to show as he was hungover, leaving the last copy of the presentation unreadable to any of the rest of us. A quick call from myself and the prof and root changed the permissions for us.

The admins exist to help others, but it does not help anyone if you just hand out root access. If there is a good reason for permissions to be changed, or packages installed etc then there needs to be a quick simple system to request the change, approve the change, make the change and log the change.

As a developer...

[Belial6]

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.

Re:As a developer...

[h4ck7h3p14n37]

I can relate to your experiences; if you get in the habit of making quick changes to production systems, eventually you're going to hose the thing, knock it off-line, etc. I work for a publicly traded company and now have to deal with Sarbanes-Oxley compliance issues. Having to document and get approval for every minor change to the production systems greatly improves their availability. I've also learned that if in doubt, don't.

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.

The line I always use is that, "robust processes must anticipate and be able to cope with failures/mistakes". Over the years, I've seen way too many instances where a process will work only so long as every step is done correctly each and every time. One mistake and you can have one hell of a mess to clean up.

Basic SUDO rights?

[Anonymous Coward]

" ... basic SUDO rights like chmod, cp, mv, ..."

You don't need to SUDO for those commands for files that you own. You can even install software as long as it stays in space that you own. I don't care what you do to your own files.

Ever hear of groups?

[Fallen Kell]

This is what they were designed to do in the first place. Group level permissions allow people who work in the same "work group" to also have a permission level to all their "group" product files.

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).

Re:Ever hear of groups?

[Anonymous Coward]

Unix groups suck. What you described is ones step above setting permissions by beating stones together.

Re:Ever hear of groups?

[msa77]

Unix groups suck.

Well, although there are things that could be improved, Unix groups are mostly OK. The problem is that modifying groups are done at a system level. If the user could at any time create a new group and populate it with the users they want, lot's of problems would be solved. (Oh, and automatically across all hosts in the company of course, not just on one host)

Now this requires a call to an admin every time. And that sucks.

Re:Ever hear of groups?

[DaveV1.0]

Allowing users to create and populate groups pretty much negates the security aspect of groups. Most users are very lax about security and also have no idea how to harden their systems. And, like it or not, good security tends to be a bit of a pain. That is why it tends to be in the hands of a few people. The are central point of contact, action, and blame.

Now, if you had a secondary grouping mechanism, then things change.

BTW, the admins could

1. create a shell script wrapper to manage what users can do with those wonderful high power commands such as chown and chmod.
2. write a modified secure version for the users to use.
3. several other things that are less secure that I am not going to bother with.

Dedicated dit to users

[dindi]

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)

I have an idea

[Julian Morrison]

Howsabout this. A second, sudo-like command. Lets call it "root". You use it like sudo, but rather than actually doing anything, it just basically logs the user, working dir and command line in a to-do list. Admin staff can browse the log via a web UI, edit each command line in a text box, check each item for "do it" or "don't", and press "go". So if I do "root chown bsmith:staff myfile; root cp myfile ~bsmith", then root will see lines like:

jmorrison | /home/jmorrison/ | [chown bsmith:staff myfile ] Do[_] Don't[_]
jmorrison | /home/jmorrison/ | [cp myfile ~bsmith ] Do[_] Don't[_]
[go]

Re:I have an idea

[tuomas_kaikkonen]

You might create a situation where the non root-users ask root-users to do something bad, but the root-users may not catch it. It might create too much overhead work for the root-users checking and double checking that those chown do not cause any trouble.

Let us consider case where the non-root user wants to enable set user-id bit for a file and then change ownership to root. The system could probably be semi-automated to check for this kind of situations.

But seriously, chown root file should not always restricted. What do you think?

Re:I have an idea

[rew]

Apparently there are systems around where users can't look in others' homedirs. Fine.

for files that others on the system can be trusted with:

# mkdir /home/public; chmod 777 /home/public

for files that require "for your eyes only":

jmorrison% uuencode myfile myfile | mail -s "here is the file" bsmith

problem solved.

Re:I have an idea

[Anonymous Coward]

that would be too easy to fool with wacky use of symbolic and hard links, etc.

I think you're overestimating the proof-reading skills of a sleep deprived admin.

Re:I have an idea

[Luuvitonen]

That's hardly "for your eyes only" ... actually not even close.

Re:I have an idea

[Antique Geekmeister]

No, it's "chgrp {staffgroup} /home/public" and "chmod 2775 /home/public". That prevents the "anonymous" user from over-writing the files there or replacing them with fascinating links or binaries that will do something really rude, and it causes the group ownership to be propagated to new files and subdirectories in that group.

Re:I have an idea

[cortana]

I think you mistyped:

% uuencode myfile myfile | gpg -a --sign --encrypt --recipient bsmith | mail -s "here is the file" bsmith

Re:I have an idea

[daddymac]

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.

Re:I have an idea

[SiMac]

You could also just use a setuid CGI in an htaccess-protected directory. There'd have to be a pretty big security hole in Apache and a security hole in your script for anything bad to happen.

Re:I have an idea

[daddymac]

You could do that. One problem you may encounter though is everything your setuid script is going to do is going to be shell, and as I recall, you can't setuid a shell script. You could do it in bash and have it exec the shell commands, but still, that script is going to have the power to do anything root can do, and it's going to be executed as apache. And it's run through a web interface.

How do you keep users from building an html form, either on the server (they have some shell access, there is a web server, they could possibly have some sort of accessible html space) or a form on their own machine that just "approves" whatever commands they want your setuid cgi to perform?

Another way would be to just give the user access to a form that a root user could check, and instead of having the cgi run the commands, why doesn't the root user simply copy and paste the command into a terminal window? Like someone mentioned earlier, email would work just as well for this.

In my office we use IRC, someone in another department needs something checked out of cvs or a permission change, or whatever else, they simple tell us (IT staff), and we do it if it seems sane. Automation is good, but too much automation is inviting trouble.

Now I'm conflicted..

[dbcad7]

After reading both you post, and your sig.

Root access is for sysadmins

[Venik]

If the user is the owner of said files, then he can chmod 'em all he wants. He can also move them, copy them, or delete them at random and then call the help desk and ask for restores. If, on the other hand, the user is not the owner of the files, then he has no business touching them on a production server. On a personal workstation - no problem. Sudo offers a good solution, when the user can identify specific things he needs to do as root and when the sysadmin has enough confidence in the user's technical abilities.

The bottom line is: the sysadmin is responsible for the systems he supports. If a problem occurs and it is determined that the user with sudo or root access caused it, the blame will still be with the sysadmin, who allowed the user to have extra access in the first place. Under normal circumstances the user does not need to have root access on a production box (although he may think that he does, but what he thinks is irrelevant... resistance is futile...). This is why we have development and test servers. Linux servers are no different in this regard.

Uhm...

[Short Circuit]

I don't know about other filesystems, but ext2 and ext3 have had support for ACLs for a loong time.

And there's Linux kernel support for other security models.

Re:Uhm...

[chachacha]

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.

A good time to ask

[Vermyndax]

This may or may not be the right time to ask, but I will anyway. I'm a Windows/Linux sysadmin hybrid, but more Windows than Linux. The reason being that we just don't have that much in the way of Linux or UNIX in place... but what is in place I help out with administering.

That being said, I would like to know if there is an object auditing system out there for Linux. If not, man it would be tremendously useful. One of the pleasures of catching unauthorized changes in Windows is to set the object audit policy at the group or local policy level, then tagging objects that you want audited and for what type of access.

Could someone educate me, either publicly or privately, doesn't matter, on a way to get this type of auditing in place for a production server environment? Or at least point me in the right direction? I realize of course this may be completely dependent on the type of filesystem in use by the machine... but still, good to know kinda stuff.

Yes you could, you are just a moron.

[Some Random Username]

You most certainly do not need any sort of write access to /bin. Install stuff in ~/bin and set your PATH appropriately. Upgrading compilers? You do not need to mess with the system at all, just install as many compilers as you want in your home dir and use whichever one you need when you need it. And you shouldn't be setting the date, that's what ntpd is for.

Sigh...

[ivan256]

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...

But for your other examples... You do not need root to upgrade your compilers. You do not need to install things in /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.

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.

Re:Sigh...

[mikaelhg]

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...

Pray tell, you think it's practical to simulate clock error detection with NTP?

Re:Sigh...

[Anonymous Coward]

And how often is clock error?

I guess that would be an easy enough problem to solve... with NTP.

Re:Sigh...

[mikaelhg]

When you develop, like the great-grandparent, networked game servers, you need to detect clock error conditions. To develop software to detect the error condition, you have to have some way to simulate the error condition. Just how complicated is this?

Re:Sigh...

[cbciv]

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...

Even if he needs to set the clock to a specific date/time repeatedly to reproduce a time-linked error? That's happened to me a few times.

Re:Sigh...

[ivan256]

Since I specifically said "on a shared system" I'd say "no." He shouldn't be doing that. Go reproduce your error on a development system.

Three words

[Anonymous Coward]

Segregation of Duties

I have root

[Anonymous Coward]

I work in a company where everyone has root on all of the develipment Unix machines. Sun, HP and even mainframe boxes. We do not all have it on our windows boxs, and that seems to work OK.

THis allows us to develp however we need to and to call the IT admins when we need something done on the windows desktops. Its weird and it works.

Someone should be fired

[AvitarX]

If you frequently need to chmod files you do not have access to then someone is doing their job wrong, but giving sudo out is lunacy.

As for the packages, install them in your home or have the admin do it.

The admin needs to know 100% what packages are installed at the system level period.

It's their job d*mmy

[Anonymous Coward]

I agree with the comment about NO ROOT ACCESS EVER.... This comment shows that the person making it has no idea what they are talking about. Software developers write software, the system is a tool and sometimes you need root access - ever tried to run snoop or tcpdump, guess what, you need root access. I agree that shared systems have to be tightly controlled, but I find that many sys admins don't get it that their job is to help the users (developers) to do their job - they think their only purpose in life is to say NO and stop them from breaking things. Maybe an attitude adjustment is in order..... (next time how about saying instead "no, but here is how I can help you get your job done") ok, flame off.

USERS NEVER NEED ROOT ON A "PROD" SYSTEM

[yosemitesammy]

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...)

chmod, mv, cp computer security conflict

[pele_smk]

If you're going to spend the money on a Beowulf cluster, I suspect you have a network security engineer or someone acting in a similar fashion. If a user was given sudo access to change permissions, move, and copy files how would you manage these changes? Do you plan on keeping a log book with the changes you've made, why they were made, and the positive/negative effects of the changes you made? In a small business of around one or two administrators sudo access loses a bit of its charm since they literally are root. Once random workers go around the office changing files, your risk management and security plan are basically screwed.

For starters, since you're asking this question about giving sub-root users sudo access, I feel your security engineer isn't working at his best. Having you guys believe in his work and understanding why his activities are needed is important in maintaining a secure environment. Obviously you question his motives.

I do have a question. If you're going to be given access to commands such as mv and cp, what stops corporate espionage in this situation? Is it a log file the admin must scavenge through for days just to search for an inconspicuous cp without an attached reason for the commands execution?

Cliff's saving us tax $$$ - - Yay!!!

[theseawizard]

That'll make a big dent in the trillion $$$ debt!
Poor SUN - hahahahahahahahaha - let's kick 'em while they're down!

UNIX has THREE levels of permissions.

[blair1q]

UNIX was designed with three (3) levels of permissions:

1. Root.

2. Group.

3. User.

This has worked fine for three decades.

If you are a user and need group access or you need something done that would alter the system, then yes, of course, you need to involve someone with more authority.

Otherwise, your normal daily tasks should only require modification of files you as a user have permission to modify.

The wide availability of linux, making every installer 'root', seems to have altered the mindset somewhat. Which was a mistake. You should have been doing very little as root, and as much as possible as an ordinary user. Then you wouldn't be on a UNIX system and thinking like a Windows user...

(N.B. In most corporate shops, even that's going away; Windows users now get far less access than they used to.)

Never.

[supabeast!]

Any user important enough to need root is important enough to have access to development machines where he or she can fuck things up with impunity. But on live systems, only a moron gives root to users - especially if those users are developers!

Administrator

[tsa]

This is slightly off-topic, but a nice story. I work in a research group at a university as a researcher. In our group we have a system administrator who makes sure that all our desktop machines keep running Windows smoothly. On my first day at work I told him I use Linux at home. His response was: "O, would you like to have an administrator password for your computer?" Which I gratefully accepted of course. And until now (two.5 years later) I never misused it so we're still on good terms :-)

Why?

[c0d3m4n]

Is there any good reason why a user would need to change files outside of their home directories? Other than a cruddy setup done by a mediocre sysadmin, in which case they probably give users way to much freedom anyway, so it's not an issue until the whole system's taken out, and needs all sorts of messy work to have up again!

Amen

[Sycraft-fu]

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.

Re:Amen

[Xouba]

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.

This is true also where I work, but we're slowly trying to change it because we need redundancy. Usually, the guy who knows about stuff X goes on holiday, or is sick, or whatever, and the rest of us are left with little if any knowledge of what he does. So we're trying to get always two (or more) people to know about any kind of stuff, to allow for safe and worriless (does this word exist?) vacations.

Re:Amen

[Zemran]

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.

I had the unfortunate luck to admin at a college where far too many had root and they all thought that they knew best what to do. No one told anyone else what they did because they all thought that it was obvious what was the right thing to do. I had no idea what was going on. I wish that more people understood that, leaving things to the guy who's job it is, is the only way to go. Then he knows what to roll back if something acts strange. If there are more than a couple of people making changes faults become buried beneath faults. It is one thing to offer advice and good advice is always welcome, even constructive criticism, but keep your fingers out.

Re:Amen

[Anonymous Coward]

A good set of policies and procedures would erradicate this problem. When a change is made document in a centralized location and notify all who would be potentially effected by the change. You can give multiple people root access if you setup procedures to account for it.

Re:Amen

[Overzeetop]

I think the problem is that some users have a real inflated sense of self importance and entitlement.

The only issue I have is when either
    (A) management doesn't realize the load they've put on sysadmins, and I have to do crosswords until the SA can get my stuff working because they're understaffed
    (B) I'm working on time-critical projects that require me to be at the office after hours, while the SA who needs to get me running is out playing with his kids
    (C) SysAdmins who have a real inflated sense of self importance and entitlement.

As an engineer trying to get things done, A and B are frustrating, but C is just downright infuriating. But you'd better not piss of the guy with root, or you'll never get your job done - and it won't be his fault.

(PS: Now I run my own company, and am root. Now that I've been root for a couple of years, I really, really want to hire someone to be root for me. It's just too much fucking work, and goddamnit I've got to be doing more billable hours if I want to eat! ;-)

Re:Amen

[Anonymous Coward]

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.

This is a very sysadminy view. Have you ever stopped to think why you have a job? It's to provide a service. For the most part, IT doesn't exist for its own purposes, it exists to support business functions.

Re:Amen

[Anonymous Coward]

Exactly!!! IT does exist to support the users. if nothing ever broke the only IT functions a business would need in house would be 1 or 2 people to handle setup on new systems and upgrades.

However,I agree that users will screw things up eventually. Some just do it sooner and more often than others. I have admined several systems in the past and have never found a problem not caused by hardware that could not be fixed by when the users came back in the next morning (NEVER). However now working in the development world instead of the admin world I had to go through all the same certs that the helpdesk guys have to have just to have basic admin rights on the machine on my own desk. Yes this was frustrating to go through, but I understand why. Around here things are loccked down pretty tight...if you don't need the rights to do your job, you don't get them PERIOD. If you need the rights it can be a pain to get them, but you will get them if you have a valid need. Still everything is logged and if your screw it up you are held responsible.

I will say this though, I realize my limitations as a user. I may have over a decade of experience as admin on M$ boxes and I am a component user for Solaris, Mac, Unix/Linux platforms. Still I would never dream of telling someone that I was qualified to admin a Unix box in a production environment. I just don't have enough experience to do it. Could I get things fixed on a machine with a couple good resources for info and enough time...Yes, but in a production environment I wouldn't ask the users to wait that long for me to find to solution and fix anything I broke in the process of fixing the first problem.

Solaris Role Based Access Control (RBAC)

[Anonymous Coward]

You should set up Solaris RBAC (Role Based Access Control), it's designed to tackle just this sort of problem. Oh wait, you ditched Solaris for Linux. Nevermind.

SUDO in a corporate world

[GuyverDH]

In the environment that I manage, only the admins have sudo priveleges for any kind of system command.

Developers that need to run certain programs as other users (such as the userids that certain application services run as) we write scripts that can only be modified by root, and then give the individual users rights to run them. The scripts are written to disallow break-outs (like interrupt, kill, etc).

The admin users do not have access to the root account - unless the machine is down, and root access is needed to bring it up. Then we get the root passwords out of a lockbox, that requires management to get access to them.

The rest of the time, the admin users execute commands as needed via sudo. Any time an admin uses the sudo -s parameter, they have to add an entry to a log book as to why, what commands were run, and for what reason. All other commands run from sudo, are logged, and the log entries record to the equivelent of WORM storage.

If a user needs something changed, they submit a request to their supervisor, who then passes it on their manager. Management has to read, understand and approve the request, before forwarding on to the admins to have the work done. If it passes admin checks and approvals, then they can get it done. If it doesn't pass, then a discussion is started, as to why they thought they needed it, and their reasons behind it. Sometimes the users make silly requests because that's the only way they could think of to get something done. Usually one of the admins can come up with a better solution that solves the user's problem, without doing something odd to the rest of the system.

If a developer needs something done, the request has to pass a peer review before the request is ever submitted to the admins. Once submitted the process flows through very much like the user requests.

So in short, users NEVER get sudo access, developers rarely get sudo access, and when they do, it's very restricted to scripts they cannot modify. All sudo access records are written to media that once written, cannot be changed.

Re:SUDO in a corporate world

[GuyverDH]

Oh - and users aren't allowed to modify their environments. ie - their home directories are read only. There is a sub-directory below their home directory where they can dork with stuff, but only there. They aren't allowed to modify their .profile / .bash_profile. They aren't allowed to write scripts in their home directories either. Their PATH variables are READ-ONLY, and disallow ./
Then again, most of our users are running financial software, and we cannot allow *customizations* for individual users.

Rootsh: a fully logged auditable shell

[cprice]

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.

configure --prefix anyone?

[kbielefe]

I've installed numerous versions of Ada and C++ compilers, window managers, gtk, qt, lyx, and more in ~/bin under Solaris without root. Almost all file permission problems are solvable by contacting the file owner directly without involving an admin, and that's usually the courteous thing to do anyway. Things that do actually require root are few and far between in my book. Even if you really need to do something regularly like restart a web server, it can be easily arranged with a one time change to a sudoers file or something. However, that is the exception rather than the rule.

MIT Athena

[Anonymous Coward]

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...

Re:Makes no sense... do you work for SUN?

[iccaros]

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.

Are You Kidding?

[nathanh]

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)?

No.

If no, why don't you

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.

If you allow root access to your knowledgeable users (ie developers with Linux experience), what do you do to keep them 'in line'?

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.

Re:Are You Kidding?

[djp928]

I've seen developers chmod 777 their files because they don't understand permissions.

Can someone PLEASE explain to me why developers do this? I can tell you from long experience as a UNIX sysadmin, developers will 777 every file they work on if you allow it. WHY IS THIS? Please explain this to me! Even the ones that claim to know Linux/UNIX will do this eventually. I have not YET seen a development environment that WASN'T completely 777 if the developers had the ability to do it.

WHY? WHY? I DON'T GET IT!

The permission system is not that hard to understand! You guys constantly remind me how friggin god-like you are because you sling code for a living, please just one of you tell me why chmod 777 is your favorite friggin command??

-- Dave

Last but not least

[dbIII]

Once one user knows a root password the person next to them gets told but not told the password policy and before you know it even the work experience kid knows it and is changing file permissions.

Eventually you get someone looking for space and you get someone deleting something like /boot/vmlinuz on a linux system and letting the magic virtual smoke that starts the machine escape.

If you can't bring it back from bare metal with little in the way of consequences then no-one gets the password that would possibly abuse it. Most developers should be able to get root on anything where they can physically get to the hardware anyway, and some will do it even if asked not to - so an answer is to let them have root on their workstations and test machines - have a good way to get those back from the dead with minimum agro, since people will panic and blame others for their own mistakes - and lock everything else down or at least put it in an unpleasantly cold room with lots of loud noises so you can hear if anyone goes in.

A great quote from someone who has been using MS Windows machines daily for ten years in an office and should know how to drive them by now: "I saved it to "C" drive you idiot, you should be able to find it there on the other computer. You mean all the "C" drives are different? Why did we bother to pay so much money for a network then?"

NSA SELinux

[Dark Coder]

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.

National Labs

[warrior_s]

I think the post is trying to say what happens in government operated labs. I can tell you about what happens in various national labs, such as LANL, LLNL, LBNL etc, since I work in one of thoes labs. Sometimes it happens that even a genuine person needing root/sudo access do not have that access because of the "undefined" security reasons. One of my colleague have to leave his job just because he was hired as a kernel programmer and was not given sudo/root access... What the hell!! In a research environment, it becomes necessary that you give users full access to atleast their own machines. In national labs, the situation is a lot worse that what you guys think.

Root access == adminstrator

[swordgeek]

If I give you root access, you are by definition the administrator responsible for that box. If you get the root password, then my next act will also be my last as root--expire the root password, to force you to change it to something I don't know.

Nobody gets root access except senior admins. Nobody gets sudo access, except for admins and DBAs. These rules also bar former admins who are currently in a different role.

My question is why did you convince them to move from a Sun to a beowulf cluster? Was there a legitimate reason, or was it a pet love of Linux?

You're kidding, right?

[MadDog Bob-2]

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.

$ ln -s /bin/sh ~/my/seemingly/innocuous/path
$ sudo chmod u+s ~/my/seemingly/innocuous/path

Figure that any chmod u+s is suspicious and will get caught?

$ ln -s /etc/sudoers ~/my/seemingly/innocuous/path
$ sudo chown `whoami` ~/my/seemingly/innocuous/path
$ vi /etc/sudoers
$ ln -s /etc/sudoers ~/my/other/seemingly/unrelated/path
$ sudo chown root ~/my/other/seemingly/unrelated/path

Figure you'd notice their subsequent use of whatever new sudo permissions they just gave themselves?

$ ln -s /etc/passwd ~/my/seemingly/innocuous/path
$ sudo chown `whoami` ~/my/seemingly/innocuous/path
$ vi /etc/passwd
$ ln -s /etc/passwd ~/my/other/seemingly/unrelated/path
$ sudo chown root ~/my/other/seemingly/unrelated/path

And, look at that, suddenly their UID is 0.

The list goes on...

Re:You're kidding, right?

[dan_bethe]

Hi there. It seems to me that whatever OS you're referring to, is terribly insecure. It doesn't work on my Linux based systems. They are correctly treating the symlink as a separate file. Regardless of their own perms, the system follows the link and respects the perms of the target file. Did I miss something?

keep them in line?????

[jamej]

"keep them in line" the arrogance of those words is so flagrant....you most be a horrible SysAdmin. How about respect, expect the best, be actively invovlved with the users. Oh, I know that's actually hard work. Forget it, just keep them in line. By the way, without "them" you wouldn't have a job.

If you need root, your admin already lost...

[bferlin]

I'll agre with the masses here, but point out it's about the admin who installed the machine! -- If you're a user... and you need root for any reason, you're not doing user things... you should be in the correct group, or all the things you need access to should be granted... if you're missing something, then you have to call the admin and let him know... he screwed up. Er-go helpdesk.

If you're in your home directory and need to alter permissions and can't? that's a problem. If you're goign through /bin changing permissions... that's a problem.

Have a chat with your admin about why you're needing it, maybe he can explain why you don't. Or at least fix what he screwed up.

Sparc/Solaris vs. Linux + Access in the Real World

[ZG-Rules]

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:

Almost without exception, these run on Solaris on Sparc. Why is this? Simply because it is very very very reliable and the support contract is excellent. Ours runs on SunFire and midrange stuff like 1280s and 890s for the backend DB with a variety of frontends from Netras to 490s.

Show me a linux machine (apart from an HP superdome possibly, but that's Itanic) that you can partition into multiple physical systems, has 6 power supplies, has the possibility of over 100 CPU cores in a physical partition, can have hardware swapped in and out live and so on and I bet you it will have a pricetag like a SunFire. I am aware that a cluster of linux machines could do the same job for less buck, but for this stuff it's much more effective to have one very large highly resilient and available server.

We do use sudo; The production DBAs can Sudo as environment users and the admins (there is more than one because unlike some poster I just read I think a single key to the kingdom is a very bad idea - but then our team has already had one auto-accident death this year.) can Sudo to root. This is purely for a tracking point of view - we could have passwords for the root and application users and let people su, but it's harder to manage. They probably could use some shennanigans to get themselves a root shell if they really tried, but we'd see them because we have good (live) log monitoring and we trust them not to jeapordise their own jobs.

Nextly, our Development MIS Systems

Some of these run on Linux (RedHat Enterprise on HP hardware if you must know), Some of them run on Solaris. Typically the ones that are developing for things that talk to existing Solaris stuff stay Solaris, new stuff goes to Linux.

The reasons for this are manyfold - but they mainly hinge around the fact that Dev systems need not be highly resilient so the bang:buck ratio for Linux on HP is better than Solaris on Sun.

Sudo gets more relaxed here - our full-time (as opposed to Contract) DBAs are allowed to Sudo to root and we watch what they are doing a little less carefully. The rationale we have as sysadmins is we don't care what they are doing on our dev system (we can rebuild the OS in minutes, if they've fscked Oracle, that's their problem); Provided they can rebuild the code in Test and DR environments consistently and documentably as part of the project deliverables, we will release it into Production.

Thirdly, Academic Development Systems

Note that I am distinguishing between MIS and Academic systems... screwups in the former cost us money, the latter may cost us Grant money in the long run but at least Payroll still goes through. Think of Academic Development as the systems people write real code on (as opposed to tinkering with Databases or SQL).

These systems mostly (if they need *nix at all) run on Linux. Flavor depends on the moment and the supplier, but there's only two Research Groups out of all the departments in College still using Suns and Solaris, and that's only because their big-money code won't yet run on Linux.

Our access rights policy is something along the lines of: sysadmins and grant owner get to do what they like. Unfortunately I as a sysadmin don't get the right to tell Professor X that he can't have full access to his £Ymillion system, so he gets the same kind of access we do with appropriate disclaimers about how we'll charge

Developers are not admins, and other essentials...

[njcajun]

> 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.

This has nothing to do with "history". While I would agree that there are things that admins do for "legacy reasons" that don't really hold up anymore, I believe that this particular rule is in place to insure the security and availability of a particular system or service. If you can tell me how root or sudo access for non-admin users lends itself to said security or availability, I'd love to hear it. Otherwise, the rule stands in my environment, and every other environment I've been in where there are more than four machines considered "production".

> 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.

Those are, I'm afraid, the proverbial brakes. Furthermore, if you truly did understand their perspective, you wouldn't want to be handing out root/sudo access to whoever says they need it. Any admin with any experience knows that when a user says "I must have root", it's usually the last thing they need. Rather than maintaining an environment where root and sudo are standard issue, it's far easier to control an environment where root is a tightly held privelege given out only to those in charge of maintaining the systems and infrastructure.

> 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)?

Absolutely not. If I were tied to a pole and placed in front of a firing squad and told to give non-admin folks root/sudo access, I'd still, at the very least, request that they draw up a waiver for me to sign saying I've performed this sin against my better judgment, under severe duress.

> 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'?

This is really kind of a ridiculous question, I must say. "Developers with linux experience" != "*nix admin". Developers are well known in every environment I've ever worked in for writing algorithms that make your head spin and then five minutes later emailing the help desk to say "Yahoo is down, can you please fix it". They aren't admins. I wouldn't care if they were. They're not admins in *my* environment, familiar with *my* environment's systems management policies, they have no clue what sort of compliance procedures we need to follow, what other users on the system are doing and the resources *they* need, etc etc, the list goes on and on and on forever. The answer is no. No means no. No is always no. When I say no it means a thousand times no.

I've even had C-level types force me to give them root. That's when the old "create-a-fake-root-account-with-uid-501" comes into play. Look it up.

Good luck.

Where I DON'T Miss VMS: Speghetti Security

[seawall]

ACL's and all the rest are lovely tools used with restraint but it is DARN easy to get into a security mess if you aren't very very careful.

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.

Re:Where I DON'T Miss VMS: Speghetti Security

[Billly Gates]

How do you tell the marketing department to read documentations created during the engineering department but not delete them? Or how do you give different departments different roles for sets of resources?

You can't just cripple everyone and give a few root with full access. Unix has no group oriented model and file attributes are simple hacks. They have no concept of group rights. Only permissions.

Sure you can abuse anything. But people need control over their own documents and some limited rights without being ok.

Re:Where I DON'T Miss VMS: Speghetti Security

[seawall]

We may be in violent agreement here. Of course people have to have access to what they need. The traditional Unix scheme isn't always enough (although it can be pushed pretty hard, eventually it can become a total collection of hacks, which is bad).

Currently I work in an organzation of only a few hundred people, with a limited number of job descriptions and not everything is on central servers. Here the old Unix scheme works fine.

But yes the group permission scheme tends to break down as an organization gets big and complicated, never said it didn't. What I am trying to say is: If you have a big complicated structure then it's a non-trivial thing to make it not any more complicated than it has to be.

The very non-trivial part comes with things like anticipating mergers and company restructuring.

what about mounting

[Anonymous Coward]

this is a development question. it would be great if one can do network based sambamounts without sudo on linux such as in hp cifsmount is separate from cifslogin how do you take care of those situations without giving user access to sudo

sudo but not access to each others home?

[Sark666]

I set up a box for a friends kids and he doesn't mind them having the ability to have limited sudo access to install software and check out new stuff. It's for them to tinker around with and he expects them to muck it up eventually. But is there any way to prevent each user from having access to each other's home? He doesn't mind if the system gets hosed, but in some cases what's in a user's home is more important than the actual system. Is there anyway to accomplish this?

Re:sudo but not access to each others home?

[eyepeepackets]

Look at changing the read/write/execute bits for the home directory's permissions. If this is confusing for you, google for a help me or a howto on the permissions system. It's not a hard thing but there are some tricks and traps so having good documentation with examples is usually helpful.

Back up the home directories with the mirdir program regularly or just tarball the directories, preferably put the backups to a different hard drive or different PC/system: This is more important than anything else you can do if the info in the home directories is more important than the system itself.

I admire your friends' attitude about his kids and their PC; they will learn much very fast and enjoy doing it. I would suggest someone examine the box regularly for net traffic and make sure there is a good firewall setup: A rooted *NIX box with broadband net access is a very nasty loose cannon.

Cheers.

Wait a minute!

[SpaghettiPattern]

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.

Not any more

[katorga]

SOX, VISA CISP, Payment Card Industry Data Security Standard, Mastercard SDP, CA SB1386, HIPAA, and a soon to be flood of personally identifiable legislation.

We are having to lock everything down.

sysadmins are there for users

[jilles]

.. And not the other way around. I'm a developer, I tend to be understanding of sysadmins: as long as they give me local admin rights to my machine. Especially in larger organizations, sysadmins can be real pain. Often they don't know (nor care) who you are. Getting anything done requires getting a helpdesk ticket, which will end up on some desk. Then maybe three days later some guy picks it up. That just sucks if you are trying to get your job done.

At my current job one of the first things I did was request local admin rights. I think the guy must have understood that I'd be inserting a lot of helpdesk tickets in his queue if they refused the request. In any case, I've been pretty happy since and haven't had to bother them since.

Question

[Apreche]

Why do users need to change file permissions? If people are sharing files then they should all be in the same group. Then all the files should have the group ownership set already. If they are managing their own files then they should be in their home folders with user ownership. If the system is setup correctly then users should never have to chown or chmod anything. If you think they do, then you have a problem elsewhere. Don't give anyone root but root. And if possible, don't even give root root. Trust noone.

Makes more sense than you might realize...

[Mr. Hankey]

There are two issues you're arguing here, one having little to do with the article. First let's look into the administrative issue.

I agree that there's little reason to give any user root access. Note I didn't say in a secure environment, a cluster may very well not even be on the network. In general, a user should not have root access even in such an environment unless they are the person responsible if the system goes down. Limited privileges may be given through sudo, but any program with the ability to modify system files (editors, file modification commands etc) should be blacklisted entirely from sudo. Short scripts which the user may not modify might be exempt, for instance if the user is developing a kernel module and the module needs to be inserted/removed. In a production (non development!) environment, anything that modifies such low level parts of the system is out the window. Starting or stopping a service such as Tomcat may be negotiated through sudo, but this should again be done through scripts which have been examined by an administrator and is not modifiable by the user.

When it comes to clustering, I disagree wholeheartedly. I've worked with several variants of computational systems, including many large systems, and I have to say that Sun is really not the best choice for brute force computation. They make excellent workstations and servers, but for throwing a lot of CPUs at a problem Linux on x86 hardware and its variants is simply a better platform in my experience. The programming environment needn't be as different as you suspect, and there are a variety of excellent clustering packages such as Scyld and OpenMosix which make clustering quite painless if ease of use is more important than the results. Typically the speed of obtaining results is the most important issue of course, and this is the area where Linux/x86 shines. You simply get more CPU for dollar on commodity hardware these days.

Be generous with root access

[Error27]

Admins and developers always fight. Sometimes it makes sense to give the admins control and other times it makes sense to give the developers control.

If it's an internal system then I would give the developers root access. The worst thing that could happen is that you lose two days work. One day is lost because you have to go back to the previous back up. The other day is lost reinstalling. If you don't have backups or it takes more than a day to recover then you have a more fundamental problem.

There are seriously a lot of times when you do need root access in Linux. For example, if you want to loopback mount an ISO image and extract some files. Sure you could copy the image to your local box, but if it's at a remote site it could take an hour and use up the bandwidth for everyone in the office. It's a small thing but there are a million small things like this and my job is to bust tail all day long and someone is going to be hurting if they get in my way.

My experience is that people will surprise you with the good things that they do when you trust them.

Advice from an old Prison Officer

[felixdzerzhinsky]

I used to work in a prison before moving into INFOSEC. One old prison officer gave me some good advice regarding prisoners. "Give them nothing and take them nowhere." I think the same regarding users on a Unix system (or a Windoze system for that matter. Give them nothing.

Oracle and government...

[nettdata]

I'm an Oracle consultant and occasionally do work for a Canadian provincial government.

They are idiots.

The "OS" guys walk around with cendescending, power tripping egos and do not allow root out to anybody not in their group.

Meanwhile, they are running stupidly unpatched Solaris boxes with tons of old, unpatched code.

We were doing some late-night failure recovery stuff, and the OS guys weren't around, and we needed root to do some stuff. We paged them at 1am. By 3am, still no call, after 4 more pages. We eventually said "screw this", and TOOK root. (The easiest way was to modify a script they'd left as setuid, but left it world changeable.... how moronic!) After dealing with this problem for almost 20 hours, I was feeling a little pissy, and changed the root password on them. They came in later on in the morning, and next thing you know, a whole gaggle of them are walking over to us, demanding to know what was going on, as they couldn't log into any of the 5 boxes in the cluster we were working on.

I proceded to give them shit for being idiotic, lazy government workers that didn't know their ass from a hole in the ground. They had a whack of code that was running that had known exploits, and their only reason for not upgrading was because it hadn't been tested and approved yet. (For months and months, it seems). To top it off, the head of the entire IT department was sitting in the cube next to us, and wasn't impressed. He gave me crap for it, but later thanked me for pointing out the issues. Since then, they've called me back to perform periodic security audits.

Not the most comfortable of situations (those guys are NEVER going to like me), but at least they learned something.

SSH+Subersion, can we avoid sudo

[HidingMyName]

Interesting post. As a developer, I sometimes kludge things (reluctantly) to make things work, but I try to avoid this in production environments. I'd like to solicit advice on fixing a (minor) but annoying problem.

In my lab, a colleague and I started playing around with subversion, and set up a repository. Using ssh to access the repostory, we created it where one of us owned it and we are both members of a group, svnusers created for the repository.

So far it works great, except, that when one of us owns the repository, say the owner is me with the svnusers group and rwx for me and group, the remote berkely db access barfs on a permissions error.

Any idea how we can get out of sudo'ing chown commands on the repository directory to fix this? Also, can I force ssh to set the group for files I update to svnusers?

Re:SSH+Subersion, can we avoid sudo

[_tognus]

I had the same issue, I think. Have a look at this link:

http://allyourtech.com/forums/index.php?showtopic= 3024&pid=34880&st=0%EF%BF%BDentry34880

Re:SSH+Subersion, can we avoid sudo

[Anonymous Coward]

Google for "ssh subversion owner" led me straight to this...

http://svn.haxx.se/users/archive-2004-11/1261.shtm l

They need privs? Ok, let's give them

[Skal Tura]

A NAZI BOX!

Let's create a host server for this setup of lots of virtual servers, they want to mangle, they'll get to mangle!

Now, give them all their own "systems", which is the standard system, ALMOST, except some files are fetched from there for services like HTTPd etc.

Now, to make it work, with little effort to administration: on every boot it's a fresh copy out of a image, overwriting all EXCEPT their home directory.

Now, add to the mix an interface to do NFS/SMBFS/XFS or anything alike, hell even FTP if that's enough, to easily add perms to some files and/or directories etc. store these configs of their virtual servers so they will be up & running again always.

I'd use somekind of network storage server/device for those home dirs & configs + logs(naturally, track those bastards!)

Also, don't allow network services on those virtual servers, ie. have them on 10.0.0.0 network so they don't get routed outside.
Route all traffic to these thru separate box and sniff all data going in & out, so it's easy to find abuse, have a script checking
special cases (someone running nmap? HELL NO!). and to make it easy to track user's doings, don't allow SSH, only telnet ;)

Now, they broke their system? Just reboot it, have an interface to easily reboot their systems (max once per hour or so)

It's simple, it's effective, it's stable for production servers, what else you need?
Oh yeah, someone comes bitching, well... you are the BOFH afterall, close their virt server ;)

as a side note: i made this all up as i went on ;)

Give you users the permissions they need...

[Simon Brooke]

... to do the things they are authorised to do, and never, ever let them have root. Seriously. Also, if you're doing anything at all important on the machine, record every root login including who did it, what was done, when, and why in a log which is not kept on the machine. A paper log book is not a bad idea, although a log kept on a separate server will also serve.

Turn to your policy

[duplo1]

It sounds like your government contractor employer does not have or at least doesn't pay much attention to their security policy. A simple, easy to follow role-based policy can go a long way. It specifies in simple terms, exactly what a user can do, can't do and must do. Each user role should be covered. Technical controls can be implemented (i.e. ACLs) to enforce the policy. Your employer should also have standards and procedures to augment the policy, one of which should be IT Change Management.

The bottom line is that developers should NEVER have root (sudo or otherwise) access on production machines. They shouldn't even have user accounts on production machines in most circumstances. SuperUser access on shared development machines is even questionable.

Make sure your users, developers and admins understand their roles and you will have a relatively happy and well functioning IT dept.

ermm...

[Anonymous Coward]

Why Linux topic has a unix logo ? :|

Never need to hand out SU power

[Anonymous Coward]

Transfering files using chmod to other users in same group don't require Root.

Way around this setup group with access to all user groups but not roots or core admin accounts. Give this to the webdevelopers they can do their job.

In case of user to user shiping I normally use a controled program that does the transfer. Ie the program is SU but the user using it is a normal user. No need for user to see inside another user accounts without permission. Normal Unix is common area or email I have a third a transfer program.

Got no root, don't need it.

[Foske]

Working at the largest Dutch Electronics Company, using Linux only. I have no root, never needed it. I can change all files I got to change, or call the owner of the files if I can't. Never have to install software, or can do it within my own account. They got a system that I can choose between 10 gcc versions, 4 matlab versions, 3 gimp versions, etc. With just one single command I change gcc release. Works fluently.

Whoever needs root has very bad sysadmins.

Sometimes sysadmins shouldn't have root

[toadlife]

Your example reminds me of an experience I had about six years ago. I had just started my current job as a sysadmin and we an entirely Windows network. The network has recently been converted over from Novell to NT4. Our "head sysadmin", who had allready been there for two years, and had certifications (MCSE, CNA, A+) coming out of his ass, and because he was the only one of us with certs, he was only one who had domain admin priveldges. The rest of us had to get by calling him five times a day to have him do trivial things like join a machine to the domain. The problem was, "Mr. MCSE" really didn't know jack about how a Windows domain worked.

So one day, our of the blue, we start getting *TONS* of phone calls from people all over saying they can't log on to their computers. As I'm answering my phone assuring people that we were looking into the problem, I notice that I can't log in either. The departnment head comes in and says she can't log in either. So I log on my machine with a local account and verify that all of the servers are up and the network is working. It is. So I start poking around some more. I open up the "Network Neighboorhood" and find that instead of eighty-plus computers, there are about ten. The ten computers were all of the servers, plus "Mr. MCSE's" workstation.

I turns out "Mr. MCSE" thought the network Neighboorhood was "cluttered" (he didn't like having to sort through all of the computers when browsing for the servers) so he decided to do some "housecleaning" - by deleting every computer account in the domain, except of course for the servers and his workstation.

We had to go out to every workstation and rejoin it to the domain.

Re:Sometimes sysadmins shouldn't have root

[BoneFlower]

heh. reminds me of a goof I made on NT4 when I ran it on my PC.

I decided. "Hey, the admin account can really screw things up if I make a mistake(famous last words). Lets deny even admin anything but read and execute to c:\winnt! Yeah, that will protect me!"

Try logging in... nothing. Can't do it. I actually made a windows system *too* secure. Good learning experience, but a pain in the ass, and if it was a system that people acutally depended on... that would have been Bad.

This is why root type accounts should only be used when actually necesary, no matter how much you think you know. Only takes a momentary brain fart to do something like this, or a slip of a finger for "rm -rf /usr/home/account/sources/" to turn into "rm -rf /".

Re:Sometimes sysadmins shouldn't have root

[SatanicPuppy]

Actually saw that happen once. "rm -rf / temp/files/backup/junk" I just went to lunch. Poor bastard was in tears when I got back...Backup had failed to restore, the usual litany of disaster. I'd given him root so he could do patches on the system, without me having to come down and do it...kinda a trial basis sort of thing.

Eventually I told him that I'd load balanced that server, so there was an identical machine sitting not three feet away, with all the same data, etc...The users never even noticed anything was wrong. I don't know why he thought no one had called...Those machines hosted a big critical app that was used ALL THE TIME. That was definitely the end of root for him.

Re:Sometimes sysadmins shouldn't have root

[Antique Geekmeister]

Oh, brother. That happened just before I started a job: someone created a cron job with a typo that flushed the company's core source control server, then it turned out that the backup system got around a limitation by turning one directory into *2000* distinct subdirectories, and it would take 10 days to get it all back online.

One of the core lessons of this applies to the original cluster manager: make sure your backups are tested for restoring system. This is different for cluster machines than it is for core server. Setting aside a few cluster machines for testing OS updates, install tools, and alternative configurations is often a very good idea, and leaves you a few spare machines that can be swapped for ones that the users manage to seriously ruin while you restore them from scratch.

Re:Sometimes sysadmins shouldn't have root

[macdaddy]

I heard almost the exact same story from a friend of mine a few months back. IIRC someone at a former consulting agency he worked for did it, or someone at one of the sites they supported, or something along those lines. I thought it was hilarious.

Re:Sometimes sysadmins shouldn't have root

[squiggleslash]

Heh.

Everyone has brainfarts too.

I've never had a problem with wildcards. I've always known exactly how they work. So I'm still trying to work out how, some time around 8 years ago, I'm looking around at /etc, and thinking "There's a passwd~, and passwd.bak, and I really should get rid of them" (first mistake), typed "rm /etc/passwd*" (because the files I wanted to delete were passwd with something on the end, right?)

It didn't even click right away. I suddenly couldn't do anything, and it took several seconds before it clicked that the error messages were because I'd deleted "passwd", because my choice of wildcard was stupid.

Re:Sometimes sysadmins shouldn't have root

[SatanicPuppy]

Yea, some other monkey in my company set up the backups on that machine; I have a morbid fear of tape, which is why I had the two machine setup in the first place. I was pretty much relying on the fact that I could sync up the two machines, and since they both had raids, I wasn't too worried about losing them both. Worst case scenario, I had solid backups of the database and all the software, so I could have rebuilt the machine in a few hours.

I was pretty keyed up for the rest of that day though...I didn't want to bog down the whole building by running my rebuild scripts, so I sat around thinking about what a bad time it would be for the other box to crash. Long day.

they can get root themselves

[Anonymous Coward]

shared Linux system? they can use one of the many public exploits to get root status if they want it.
oh, you do make sure that the systems are completely fully patched, arent running the supplied kernel
and arent running packages that are not needed at all do you?

... right ...

[Anonymous Coward]

cp /bin/bash ~/foo
sudo chown 0:0 ~/foo
sudo chmod 4700 ~/foo
~/foo -e vi /etc/syslog.conf

Just wait for SELinux to be mainstream

[Anonymous Coward]

The system administrators in some environments may not have access to do some of those commands listed. That function may be reserved to the "security administrator" and no I'm not kidding. I'm a system administrator by trade and I know this is coming at some point in our environment. There are a great number of details that would need to be worked out before we run down this path. I work for a fortune 500 company and we do not work with the DOD.

In our environment, we have application accounts and we have different rules for different classifications of systems. On our development environments, the developers have access to the application account(s) associate with the projects to which they work. On production environments, because of good old SOX compliance, the developers can get access to the application account in emergency situations, but the security and the change management folks will have a full keystroke access log of what the developer had done and the projects AVP is notified of the unscheduled changes. At this time we are using PassGo's UPM (this is almost identical to Power-Broker) to manage and control access and it works pretty well for interactive commands.

Much of the documented need was for SOX compliance for our financial system, however we have some critical safety systems that the same rules were applied some time ago and rightly so more rules are coming.

Good luck.

Get a trouble ticket system for admin changes

[brunes69]

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.

Agreed

[Kludge]

Most programs can be compiled & run without doing a system-wide installation. Users can put their own binaries in ~/bin and set appropriate paths for required directories. I remember I had to do this 15 years ago with 'screen' on a system (I had a terminal), because the sysadmin didn't want to install it. I do it today with my custom compiled version of R.

Voice of the BOFH

[Anonymous Coward]

The only boxes developers should ever have root on are their very own clone-drive virtualized sandbox instances, where they can develop on and rm /usr/lib/* to their heart's content without having to call us every time they screw something up.

Short and long answer:

[IdleTime]

NO!

know your role

[Anonymous Coward]

You really need to get over the fact that you're not a sysadmin and therefore should not be granted rights to do administrative tasks on systems. What you were in a previous job is irrelevant. You're currently a developer, so focus on that rather than being a pseudo admin.

Government Contractors don't want root.

[jellomizer]

You really don't want to have any more access then you really do need. If they gave you root access and something happened to the system they will point their fingers at you faster then you could type "df -k". And it will be up to you to prove that you didn't do anything to crash the system (assuming that you didn't do it). Governments employees are Union workers and Unions really hate contractors because we tend to be more efficient then Union workers without paying the union dues, so if they could find some proof of a mistake by a contractor they will be merciless. Hopefully you are being paid by the hour so you will get paid even while you are waiting for the sysadmin to install the package.

Yeah but....

[veg]

OK - end users fair enough, but what about the users who *manage* the box ?

At my last job the audit procedure was totally mental. An example: We were the engineering team for the global email backbone (around 90 servers). Our software and scripts run on all of these servers (as root in many cases). But we weren't allowed root access, so we couldn't install any thing or even debug live systems properly. That was the job of our "ops" team. We package the software, they deploy it. Any problems, they tell us and we have to fix it and redeploy it. Even though our ops team had root, they couldn't just login and do things that needed doing. They needed to file a change request - which took a week and had to be approved by about 10 people.

BUT
Despite having root they couldn't just do what they wanted. Every su was logged to a database and they had to give reasons for every one. And as for adding users, modifying system files, fixing permissions....nope - that was the job of the SAs!

So, when a problem occured on a production box, rather than logging in, suing and fixing it, the procedure was as follows:

• I notice the problem.
• I send an IM to my boss.
• My boss organises a group IM chat to discuss the issue.
• The result of the chat is that the "SA team" need to be contacted as none of us are allowed to login to the server (for corporate reasons).
• The boss asks someone to page the team and to setup a conference call.
• A conference call is established with 7 people, all in different countries, and we spend a while waiting for the SA team to respond to the page.
• Eventually the guy arrives and we try to diagnose the problem by telling the guy (who, despite being very well meaning and competent, doesn't speak very good english or have a very good understanding of the systems involved at all.)
• We realise that the only way we're going to solve it is by getting a login into the affected server.
• We try to describe the measures necessary to the SA guy to perform this and fail...
• ...loads more tedious crap until we all realise that unless we leave the call we will die there.

I resigned.

Re:Yeah but....

[avdp]

Yes, I am seeing variations on that theme where I work as well. Not just on systems, but on databases as well. For example, all in the names of Sarbanes Oxley, they've removed any kind of insert/update/delete rights to data in databases to developer accounts. Nothing but select (and I should feel lucky to have that much).

Like all well-meaning policies, somebody that didn't really know what is going on (in this case the DBA group) went overboard. The problem is: because of Sarbanes Oxley, it's a problem if a developer goes and change financial/accounting type of info directly in the database. Fine. So what do they do? They implement these rules on every database and every table, even databases without any financial/accounting impact whatsoever. So if I was storing application settings in the database, I can't even change those without jumping through tons of hoops. Urgh... Frustrating...

Re:Yeah but....

[Anonymous Coward]

The accountants now can't do what they want, so as they run business, they make sure that no-one can do they want, even if what they want to do is their job!

Re:Yeah but....

[cmdrbuzz]

In the bank that I work for (UK), developers have no access to production systems. Not read, absolutely not update or delete rights.
Our customer records are totally inaccessible by the programming teams, unless they request a copy, where the personal data has been updated to Mr A Smith, Mr B Smith etc.

The only people that have access to read everything is Group Audit, and I have to file a change request to get anything updated.
As part of the Special Investigations team, any account or record that I look at is logged, but I cannot update any system that has a production marker, so all the applications we develop here are classed as development apps, even though we use them as part of the investigations.

So I guess its not just you with the over-the-top procedures.

What the admins did...

[vinsci]

...at ftp.funet.fi to allow tens of people to move files around, without su access:

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

Is it secure this way.

[DCFC]

If I understand your process, you have some poor guy whose job is to handle a horde of little changes. Very hard for someone to keep track of these things to work out their overall consequences; it should be automated. But the implication is that it's not and I'm guessing he uses his wit and wisdom to spot obvious bad things. Worse, you may have a team following someone else's rules which they neither understand nor care about. Also a helpdesk team finds it harder than an individual to keep a view of the overall system. It's easy to see that going wrong by simple human error, which is more common when you have to have a relatively smart person doing a job that 99% of the time is dull. I bet there's more staff turnover in this role, eventually of course the point of stabiity is when you end up with someone who can't get a better job, hard to see that as good. How do you keep them sharp for the It seems to me that a rules based system could capture the essence of this job, and something that will make your security audit peple happy is that the software can be tested. I wonder if there exists such a tool already ? (feel free to reduce my ignorance here) It strikes me as a rather good candidate for an open source collaboration.

Why we don't do these things.

[pasamio]

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)? The hard way: $ sudo cp /etc/shadow /tmp/researchfile $ scp /tmp/researchfile otheruser@randomhost:~ $ echo "/usr/sbin/shutdown -r now" > myscript $ sudo chmod +s myscript $ sudo mv /var/log /tmp $ ./myscript Really the long way of doing things, too much sudo! Lets rewrite 'myscript' $ cat myscript cp /etc/shadow /tmp/researchfile scp /tmp/researchfile otheruser@randomhost:~ mv /var/log /tmp /usr/sbin/shutdown -r now $ sudo chmod +s myscript $ ./myscript Hell, I didn't even need to use 'cp' and 'mv' with sudo, only one entry, a permission change! (This is also assuming that you're running a system which is configured to wipe /tmp as part of the power cycle) No sudo on chown or chmod or chgrp. No sudo on cp or mv (especially stickybit on directories set!). You have to have great trust in your users because those three commands just lost you a system...oops.

there's already a system like this

[weierstrass]

for asking the sysadmins to do stuff for you.

it's called email.

Re:there's already a system like this

[Thuktun]

The point of his suggestion is that it provides a process for a root-privileged user to approve batches of requests and automatically process the approved ones. This scales much better than ad hoc email requests.

How to compromise systems using chmod, cp and mv

[pasamio]

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)?
The hard way:
$ sudo cp /etc/shadow /tmp/researchfile
$ scp /tmp/researchfile otheruser@randomhost:~
$ echo "/usr/sbin/shutdown -r now" > myscript
$ sudo chmod +s myscript
$ sudo mv /var/log /tmp
$ ./myscript

Really the long way of doing things, too much sudo! Lets rewrite 'myscript'

$ cat myscript
cp /etc/shadow /tmp/researchfile
scp /tmp/researchfile otheruser@randomhost:~
mv /var/log /tmp /usr/sbin/shutdown -r now
$ sudo chmod +s myscript
$ ./myscript

Hell, I didn't even need to use 'cp' and 'mv' with sudo, only one entry, a permission change! (This is also assuming that you're running a system which is configured to wipe /tmp as part of the power cycle)

No sudo on chown or chmod or chgrp. No sudo on cp or mv (especially stickybit on directories set!). You have to have great trust in your users because those three commands just lost you a system...oops.

(grr, forgot to switch to plain old text!)

So is your sig meant to be ironic?

[nazsco]

> Users != Root.
> ...
> --
> "Those who would give up essential Liberty to purchase a little temporary safety deserve neither liberty nor safety."

virtual pc

[devonbowen]

One of the places I contract solves this problem by providing everyone with Virtual PC. They have Windows boxes which are locked down but you're free to do what you want with the Virtual PC. Yeah, it's slower. You're probably not going to run any batch jobs with it. But it's great when you need your own tool (or OS) and can't convince the sys admin that you need it. Given that it's a Windows shop, I couldn't work there without it.

Devon

Handling root access

[ajkst1]

If you allow root access to your knowledgeable users (ie developers with Linux experience), what do you do to keep them 'in line'?"

You put a stipulation in the Acceptable Use Policy (assuming your company or business has one) that any abuse of resources they have will result in termination. If you have a good logging system, any abuse will be quite evident and allow you to back up that person's boss in the termination.

Never on production

[msobkow]

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.

Re:Never on production

[Anonymous Coward]

"Rogue users"? Man, I'm glad I don't work where you do. When I need some software, I go get it, build it, customize or debug it as necessary. If I had to wait for an admin to type the magic password or get approval for installation of software, I'd spend most of my career twidling my thumbs. (My machine is an engineering tool, not a word processing terminal. This is as it should be.)

Re:Never on production

[Anonymous Coward]

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.

Well, your philosophical stance aside, if users desperately need some piece of software without going through the red tape, they can simply install it to a subdirectory of $HOME and put that in their $PATH. I've done that many times on machines I haven't had root to.

One of the great things about Unix-like systems is that to "install" software you usually don't need to be root. In many cases ./configure --prefix=~ will do just fine.

You're wrong.

[FellowConspirator]

There should be absolutely no reason that a user should need to sudo to change permissions, copy an move files, etc. That's something that should be done explicitly by the systes administrator.

We're currently setting up a Beowulf cluster and my job is to manage the queues, setup the resource management, and tune the scheduler to optimize the performace.

I've never seen a situation where anyone has needed to change ownership of a file except for where someone departs. De rigeur, you put in a request to the admin to chmod all files under that user id to g+r and directories g+rx. That's it. Anyone in the person's department can then copy out whatever they need.

Install software? We simply provide the software with instructions, and a log of installation on another machine -- or a binary RPM -- to the admin wit a request to install it. It's not like we install applications every day. This is doubly important in a Beowulf cluster since you need to sync the software amongst the compute nodes.

No, if you find yourself wanting root access for such things, then you are doing something seriously wrong.

Keep Solaris and use Zones (aka Containers)!

[Zemplar]

Why not just keep Solaris (10) and setup your environment using adjoining clusters that you could safely delegate some [zone] "root" access to if required? The RBAC is also very good and would likely accomplish the same goals.

Root

[greening]

I run into the same problem at my job, PHP programming and some system administration. My job would be much easier if they gave me the root password. Currently, whenever I need the permissions on a file changed, I have to ask the "sysadmin" (I do more system administration that he does) to login as root and change them. Not to mention that I write some scripts and run them on live sites, I have to ask my boss to login as root on my computer so I can write the scripts.

Their reasoning behind not giving me the password is that they are very secure about who has access and who doesn't. So, the workaround I've come up with, I just leave an SSH session running with a root account logged in. They know I do that and they called that a good idea when I told them. I don't get people sometimes.

How I deal with the problem: Policy

[Anonymous Coward]

I'm a long time contractor, run Solaris, Tru64, FreeBSD & Linux at home and typically dictate system admin policies. I do NOT have root access at work. At one job I threatened to write and run a program to change the root password to a random string if anyone tried to give me root access.

The fact that you asked the question is sufficient grounds for refusing to give you privileges.

The correct answer is appropriate system policy, for example, make /usr/local (or /tools ) 1777. I maintained a large collection of open source software for 3 platforms as a spare time activity that way. Whenever I needed a package, I compiled and installed for all 3 in succession. My current shop is too screwed up to make that worth doing (i.e the security managers don't understand the concept), so I just build for ${HOME}/${ARCH} when I need something.

If you *reallY* need to change ownerships often you need to examine your premises. You're doing something wrong.

Otherwise you do *not* need root access. I *do* have sudo privileges to mount USB drives on a Linux box. The senior admin and I consider that a botch by a junior admin that isn't worth the trouble of fixing.

In short, focus on getting appropriate policies established. Root privileges are just a dangerous band-aid.

I'm the original poster...

[Anonymous Coward]

Thanks to everyone that replied - I expected most of the "You will never ever ever ever ever need root, if you need it you suck!!!" posts. Glad to know that /. doesn't change over the years. :)

Ok - to the clarifications.

First, our admins are for the most part clueless. One in the entire group has a clue, and he's the new guy.

Two - I am experienced but don't consider myself anywhere near an expert. I know I don't know everything and admit to much ignorance on Linux and Solaris. I don't like to mention them, but I'm an RHCE and a SCSA for Solaris 2.5. I can't give too many details because I know our IT guys are avid /.ers. :) I've never touched a Microsoft certification nor book, and at one time was working on getting my CCIE. Yes - I am just as clueless as the rest of us, but I at least used Netscape .99, learned Linux using Slackware with the 1.1.5 kernel on a 486 DX 100 (that was my news server), and got a overall 98 on the RHCE exam. If none of that means anything then cool - no big. :)

Three - our environment is one of the most broken-in-the-name-of-security-through-obscurity networks ever. They don't even allow ICMP because of their security "mindset". I can't friggin ping my own servers to check to see if they're up. Yes - I know about opening a socket blah blah blah.

Four - The distro they chose is an offshoot of Redhat (remember, I am trying not to give TOO many details - I do value my job). Most of our Linux desktops are EM64T or x86-64. The problem is when we need to use 32-bit apps. The current distro is quite shy of most 32-bit libraries. Yes - I use LD_LIBRARY_PATH. Yes - I compile / use --prefix with configure to send it to a filesystem I actually have privileges for.

So - that's my background. The main need for sudo access is for changing file permissions on stuff I don't own, is completely wrong for our current standard (wrong groups, etc), and is usually in the wrong place. I do NOT want sudo / root on a production system (the cluster, for example). I am speaking of having it on my Linux workstation and the numerical modelers' workstations. Have I written a stupid set of C++ that looked for a specific library in a specific path? Sure - but I $#%^#$ed that up years ago. The main point I was looking for and admittedly screwed up in not specifying well was do you allow developers sudo on their personal workstation? If so, do you have problems. If not, why?

Yeech - I'll have to submit that later. Good discussion though. :)

Here is the root password...

[Sogol]

And here is your new pager. You are now on call for anything that may go wrong on the system.

They're called ACL's

[Thaidog]

If you need to keep a ton of people "in line" on a UNIX system your only real choice is to ACL up all the files they access.

Think it through ...

[Y2]

In the old days when VMS mattered (to me), there were 35 or so different privileges a user could have. Most of them were functionally equivalent to "ALL," in that a user with such a privilege could perform a series of actions that would lead to actually having all privileges.

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.

All users should have root

[Danathar]

It's the same thing as Firearms....if everybody was REQUIRED to keep a loaded firearm on them at all times (and required to pass a course to use it), everybody would be a LOT nicer to each other.

Knowing that everybody has root means that if you screw up someone else....provided you have'nt rm -rf'd / you can go screw them up! (yea! baby!). If if they did rm -rf / well....then you can get together with your pals, pull out your firearms and shoot the bastard!

All you need is vi

[Anonymous Coward]

In our environment we were given a few rights like more, ls, tail. I manage a propriatary package for IP address space management that is installed as root. All the config and log files, startup/shutdown/management scripts are owned by root. My coworkers and I kept running into walls in the course of doing our daily work. Eventaully I just asked for sudo rights to vi so I could at least edit config files. Everything has been dandy since then.

Good advice on any platform...

[Karl Cocknozzle]

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.

This is good advice on any platform... mod parent up!

Seems obvious to me

[Anonymous Coward]

Why would a user need root access? What files do they need to change permissions/ownership on that they do not already own? If a user can read a file they can make their own copy and do whatever with it. Any user can install any worthwhile application into their own userspace (usually, always if source code is available...go FOSS!) without interfering with any other person's files. I want Firefox 1.5 beta? I can download the tar and run it without installing anything. Does anybody else on the box suffer from my poor administration of that browser? Of course not. I want to compile? Everybody has access to gcc. I want to change my path? Of course I can change mine and even make it permanent by manipulating the files I OWN in my own home directory. I want to catch a virus? Who cares. Nobody else on the box will suffer from that unless the virus takes the entire processor and, in that case, a real admin with root can kill my process, my user, and me for being stupid. I want to spy on other people's work? No. A worm from my Exchange account wants to access a low-order port to spread (running through CrossOver or something, I presume, since we're on a secure OS here)? NO. A virus/worm wants to manipulate system files? NO. Malware wants to install and track usage on the server? Maybe just for my user (punishment for being stupid) but certainly not for the entire system. Again, NO.

So what the users always claim is that they know this application or change is for the good of the World. Firefox 1.5 is officially out so we need to make it available for everybody. The simple response is as follows:

Changes to the World should be done by a deity. root == deity. johndoe != deity. If what johndoe actually proposes is correct that should be done in test and then implemented (by deity) on the production system. Have a policy in place that you can refer to that states that everything must go through testing before going in production. Users do not, ever, at all, need any kind of unlimited root-ish power on any box except maybe their workstation that you can re-image in 20 minutes when they hose it. It's the admin's job to administer/administrate/whatever. It's their job to program little apps. Let them do that, you do your job and keep them from trying to do yours.

Re:Keeping those developers "in line"

[Anonym0us Cow Herd]

They all have the root password to their individual laptops.
....
If you bomb my server, I'm going to make sure you never have access to anything, ever.

The original article asked the question...

If you allow root access to your knowledgeable users (ie developers with Linux experience), what do you do to keep them 'in line'?"

How to keep those developers in line? Establish a policy...

If you get out of line, you'll end up on a Windows box!

Nope

[The Spoonman]

I would never let a developer have any kind of admin access to anything. They're just over-glorified users who think they know what they're doing. Being a developer does not make you an IT person, despite what management thinks. The reason you're so locked down is because you know just enough to be REALLY dangerous.

!r

[neo]

I once had a friend convince me that there was no way that the system would allow me to run back in my history and execute a command as damaging as:

>rm -rf *

He told me that it would clearly go back and execute the command for rebooting that I had done earlier. The look of horror on his face when it started deleting files was priceless, particularly since I had just cd'd to the root directory.

But all was not lost, as soon as it got to the rm command in the bin directory it stopped. I have since hardlinked rm to 'a' on the root directory.

groups + sudo can allow installation rights

[Khopesh]

I agree with the parent post; groups eliminate most of the need for root. A cron script to change permissions should do 'chmod g+w' ('chmod g+sw' for directories) instead of 'chmod 770' which makes blind assumptions.

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.

Milo's story

[OhHellWithIt]

I worked with Data General systems for a number of years in an office run by a government manager named Milo. When the DG went in, one of the secretaries to a director in Milo's division heard there was a thing called "superuser". She buttonholed Milo in the hall and demanded that she be made a superuser.

Milo thought for a second. Superuser in AOS/VS was equivalent to root access on a Unix system, and a superuser account can delete anything and everything.

"Okay, Helen," he replied, "you're a super user!"

Placated, Helen went on about her business. Milo didn't have us change anything about her account, and she never raised the issue again.

chmod and cp as root?

[Syberghost]

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.

Cost of security

[tius]

I'd really like to see a business report on the global cost of security measures. I.e. all the forgotten passwords, all the time wasted figuring out that some security measure was silently put in place, all the scrutinizing of systems & code, all the new wonderous fix it products, all the infestations of viri and other crud of the net, all the heavy retro fixes (ever fixed up a TCP/IP stack?)...

Seriously, I suspect the cost out weighs the cost of a breach; if not locally, then globally. The fact is that the paranoid world of security eats up an insidious amount of resources.

Unfortunately, it's a cat & mouse game where one leads to the other; i.e. a bad apple leads to more security, and more security challenges a bad apple...

Re:Cost of security

[Cid Highwind]

What's the alternative to security?

Should we toss out any machines that get so bogged down by spyware/viruses/spam relays/DDoS bots/warez FTP servers/whatever that they become unusable, and buy new ones? That will get very VERY expensive in a world where unpatched Windows machines get compromised within 20 minutes of being connected to the internet.

I'm not sure I agree.

[Richard Steiner]

So do you also implicitly agree to support anything the users want to have installed?

Our Solaris sysadmins have a better (IMO) policy on our development servers:

(1) They will install software packages on request if a few users have a legitimate need or if it's otherwise considered to be really important for a product/project.

(2) If you, as a user, want to install something nonstandard, go ahead and figure out how to do it, but you have to support it yourself. I've done this with tools like mc, DDD, vim, and a number of other utilities I consider useful.

(3) Software installed by individual users will be removed if it causes any issues.

That's for DEV boxes, though. QA and Production servers are locked down tight, and only #1 applies, but they tend to be extremely fussy about what is allowed (almost nothing).

why do they need sudo for chmod?

[whitroth]

I mean, either they're in the same group, at least, as the file they need to chmod, or they're not. If they really *should* be able to, then someone's got the environment screwed up, and it's putting ownership and permissions on files incorrectly.

In either case, they don't need sudo. I give only certain selected users sudo; normally, the team lead, or senior tech person, etc, and that's only if they really *do* need it.

        mark

Troll article

[Anonymous Coward]

You are as much an ex-unix admin as I am the queen of scots!
End users do not get sudo access! and they don't need it to
run any of those commands. It sounds to me like you have no
business dealing with a secure environment.

Why I need(ed) root

[Anonymous Coward]

I like the principle that only admins have admin access and developers have exactly the access they need to do their jobs, but how often does it work out that way (besides in a well-run VMS environment)? Sys Admins seem to be just as understaffed and under trained as anyone else. I needed root access because someone needed to do their job. Since they were my machines, my apps, and my 24x7 support hassles, I made sure they were set up and maintained correctly regardless of any obstructions. I even volunteered as temporary DBA for four weeks since that was the only way to get changes done to a database that was dedicated to my app but I wasn't allowed to make and the DBA "didn't have the time". Fine, I'll do your job too and help out the other developers while I'm at it. If you want to restrict my access, you first need to make sure I have enough access to do my job, then you need to make sure you do your job. Of course you're always free to take my pager and my 3am support calls.

Re:Why I need(ed) root

[Anonymous Coward]

Oh yeah, also ...

It's a nice theory to allow admin access only to admins specializing in a system, but again, when does the real world work that way. If I'm on the hook for 24x7 access to my system running US$100M's, I don't have the time for you to mosey in a few hours later nor do I have the patience for the Windows admin to bicker with the Unix admin to bicker with the VMS admin (back in the day) to bicker with the DBA. It's my 4$$ on the line if something doesn't work and if you can't help by doing your job, get out of my way and I'll do it for you.

How much would user-local apt / dpkg help?

[DoofusOfDeath]

I wonder, especially as Debian and Ubuntu become more popular: How much would users' desire for sudo access go away if apt / dpkg had the ability to install software for just the current user (and thus didn't require root)?

I know that in a home environment (such as if I'm setting up my parents' computer), I'd be a lot more comfortable having them use a version of Synaptic that installed software just for the current user. That would basically eliminate the need for them to have root access at all. Maybe a similar thing holds true even for most developers.

Granted people can usually install software for themselves by compiling the source code, but to require that is to basically ignore all of the benefits that apt / Synaptic offer.

(If you're a Gentoo, I think the same point can be made by using a find/replace on the terms apt/dpkg/synaptic.)

Re:How much would user-local apt / dpkg help?

[Anonymous Coward]

For companies on Debian, I've always liked the idea of setting up an internal debian package repository and putting only that repository on the sources.list. Then the workstations would all be given a minimal install and the users and add anything they want that exists in the internal repository via a sudo'ed apt command.

2 quick points.

[jotaeleemeese]

Hire competent SAs. I am one and happen to administer such a system where the application team have no root access. They tell us what to do, we do it.

Easy really. Oh yes, pay them some ENglish classes, brng them to your country for one month so they become more profficient. There are solutions for all your problems.

2nd point: ensure you have a proper problem tracking software (it could be something as simple as a Wiki). FInd problem, document it on the problem tracking application, call the guy tht has to solve the problem. All this conferencing sounds a lot about tumping chest competition and less about solving the problems given the legal and auditorial limitations nowadays (thanks Enron).

Re:2 quick points.

[bckrispi]

Easy really. Oh yes, pay them some ENglish classes, brng them to your country for one month so they become more profficient. There are solutions for all your problems.

Thanks for the irony! :P

Never ever. No. no. no.

[jotaeleemeese]

That is it really.

Do you want some degree of accountability for what is going on on the systems?(desktops included, many around here are quite cavalier about those when they have the potential to create as much havoc as a server).

Yes? Good, then only SAs get root. No exceptions.

Re:Makes no sense... do you work for SUN?

[boner]

You are correct, the name is indeed Trusted Solaris, my mistake.
And yes, I am aware that Linux has achieved PL4+. My posts are not intended to be negative about Linux' capabilities. My posts are intended to point out that some of the reasoning presented by the original poster is flawed.

Don't give them full control - except with Windows

[gamlidek]

I'm still pissed that Windows accounts need to be part of the Administrator group to get anything done. Sure, you _could_ create a second local user not on the domain to install things locally, but Windows doesn't exactly make it easy to switch users. Folks don't want to close everything they're working on down just to install a simple little app that they need... Sure, you could _also_ "Run as..." and pick the local account, but even that seems to have issues sometimes with permissions -- which seem to only be useful for making things complicated in Windows since they're never really used correctly and most of the time end up being turned off to make things easy. Can you say "Share everything to everyone and let everyone have Full Control"? And explaining these kinds of "tricks" to users? Don't even get me started. Basically, with Windows, ease-of-use has won out over security, although some might even argue that there was never really a battle between the two. People don't want to be annoyed, which still perplexes me that Windows is the de-facto choice since I find it nothing but annoying.

/gamlidek/

P.S. -- I happily converted to OS X after a decade of linux use.

Developer Access

[KillerBeeze]

If you allow root access to your knowledgeable users (ie developers with Linux experience), what do you do to keep them 'in line'?

You can't keep developers in line! You just keep backups up to date and keep your fingers crossed. lol

Groups+User Private Group+Delegated Group Owners

[Chris Tyler]

Groups can do lots of useful things -- but if you use groups with a User Private Group scheme (like RedHat's) and delegated group administration (groupmod -A on some systems) then they really take off.

(Correction)

[Chris Tyler]

Whoops, of course that should be |s/groupmod -A/gpasswd -A/

root not essential even to install softwares

[phill7]

As anyone knows, in any *nix systems, a user is usually the "root" of its own user directory. He can use this priviledge to install there softwares and services with a minimum of hack. If he's mean, he will even be able to compete the sysadmins by making his self-installed softwares available to other users. On the edge, a talented programmer can even install a virtual OS in it's user directory and manage it as he see fit. Even Windows have (a bit) more control over this.

Here at work, our AIX administrators are not very interested in their administration tasks. All they want is to give us a minimal interface with a minimal set of programs for them to maintain. In a way, I don't blame them. But I sometime need to have softwares not necessarly critical and that I'll be the only one to use. Since I know they wont want to spend time on that, I download and compile them myself and install them in my home directory (which provides $USER/bin, $USER/lib, $USER/share, $USER/var, etc.)

For this reason, I harldy see the reason why I should be root on a machine, unless maybe it's an unshared workstation or unless it's my home FreeBSD server ;-)

Bad Idea

[milesbparty]

If you're an admin, do you allow your users basic SUDO rights like chmod, cp, mv, etc...

That's a bad idea. So I'm a user, I guess I'll just write a script, use sudo to change the ownship of the script to root, then use sudo to cp it to /usr/bin/date (or whatever). Or even better, I'll write a script, use sudo to chown it to root, then use sudo to chmod it to 4777 (I assume "etc..." would include chmod). Woo hoo! I can do anything I want on the system. In general, chown and chmod are very bad things to sudo!

Also, having the responsibily of root is a bad idea if you don't know what you're doing (unless you really don't care about your job). Not to mention, the person who screwed up the system is not the admin; I am. So I'm the one that's responsible for fixing whatever the user with root access breaks.

Bad developers

[Anonymous Coward]

I've work where developers assumed the programs they developed were run as root. Any attempt to correct this is a huge battle.

How do you force those developers to develop programs that run as a regular user?

I'm currently using sudo /usr/local/sudo/some_script. They can view the script to see what it does. They can't modify it, etc. After awhile, some are convinced they really don't need root.

On previous systems they ran sudo logging_script that was basically sudo su with a wrapper that logged all keystrokes so we could find mistakes. One user installed a package on the wrong system & wiped a bunch of things out with it.

BOFH

[karearea]

I'm a windows admin and I take the full view that 'I IS GOD' everyone else (including my other personality) is a user.

When I first started where I am, the IT staff had domain admin accounts - that is me as me was a domain administrator, I didn't need to login as administrator to change someone's password, when I was writing something up in word I was a domain admin ('great' for changing the word global template). That was soon changed. Now there is me as 'pleb' and me as 'god', helps with the separation of roles (of course with terminal server, I have a session of a me as god running behind me as pleb). This model is critical in a environment where there is a 'communal' resource such as a terminal server or networked/shared applications - you can't have random people dicking around with them.

Sure it means that some people get upset that they can't do things (don't get me started on people wanting to install a new browser because some website was badly designed). I as pleb have the same issues that they do, I as god doesn't do things like open word documents or browse web sites. Of course there are also some applications that think they need write access into silly places like the root of c: or want to keep the data in the same place as the application :-( I try and explain that NO one person or application is more important than the network and the business that the network supports.

I even have my home machines setup in the similar fashion (I'm going to have to logout as me soon to update gimp, winamp and windows). I suggest to people when I help with their home machines that a similar security model is the safest thing, some think it is a good idea, some get sick of not being able to install any old 'junk' whenever they download it - I don't work with their machine a second time.

I get accused of being a control freak, but to be honest I don't give a shit because it balances out - at other times they tell me that the horror stories they hear of other networks don't seem to happen where I am (touch wood, throw salt over the shoulder, cross fingers, sacrifice a goat etc)

Conditional agreement.

[Richard Steiner]

I agree with the general sentiment -- programmers who aren't curious and who don't like to take things apart (either literally or figuratively) tend to be poor programmers, and people who lack even a basic sense of curiosity about their development environment will generally fail to learn much more about it than the minimum amount required to do their jobs.

I've worked with many of those people over the years, and it can be frustrating.

However, I'm not sure that maintaining one's own box is a valid measurement except in those cases where it actually means something. :-)

I've held four corporate software development/support positions over the past 17+ years, and I've never had a box under my own control that was even remotely similar architecturally to the machine/environment on which I was doing software development and support.

People aren't generally given their own mainframes or their own Sun boxes in the corporate environments I've been a part of -- instead, they use their own local Mac or PC to access a centrally-administered development hardware.

On the other hand, I also tend to learn about and hack whatever I can both at work and at home, which is why I have my own custom editor and various other utilities in the mainframe environment here, why I'm wandering out and bringing in various utilities to try to make my life under Solaris easier and more efficient, and why I'm constantly asking questions of the systems support people that they often can't answer. Too many people are content to use the default/minimal toolsets, and while that often works quite well, there are times when those tools really suck compared to stuff other sites have developed and are actively using.

The software development world is a series of isolated ponds, and too many people are content to play in the shallows when there are *boats* sailing around out there... :-(

A somewhat late resolution - zones or Xen

[davecb]

For each application to be run, create a zone
or virtual machine to run only that application,
give it a directory tree from a shared NFS or
cluster server, and give the aplication admin
the ability to su to root in that zone.
    She can then grant sudo rights to developers
when a reinstallation or bug-fix is needed,
but not affect anyone else.
    In addition, in a beowulf-like array, one
can put clones of the zone on all the machines
where you want to provision the app, and use
the master copy for acceptance testings before
rolling it out to one node after another.
    A roll-out tool that can do change reports
is a good extra to throw in here.

--dave

Re:Groups+User Private Group+Delegated Group Owner

[Anonymous Coward]

Please... Why would I want a User Private Group? That's what usernames are for. Delegated group administration == good; UPG == gid pollution.

sudo access to chmod? no way...

[Proteus]

Hm, sudo access to chmod?

$ sudo chmod u+s /usr/bin/vi
$ sudo chmod u+s /usr/sbin/visudo
$ visudo

Seems like a bad idea. Or, even less detectable if I also had sudo access to cp/mv:

$ sudo cp -p /etc/sudoers ~/
$ sudo chmod a+rw ~/sudoers
$ vi ~/sudoers
$ sudo chmod 110 ~/sudoers
$ sudo mv -p ~/sudoers /etc/sudoers

sudosh

[darkuncle]

http://sudosh.sf.net/

Fixes the one weakness in sudo (lack of logging on root shells) that people have been complaining about for years. Log everything that happens in a root shell (sudo -s, sudo /bin/bash, etc.), including keystrokes within editor sessions, as well as timing information (exactly when and how quickly things were typed), and playback recorded sessions later. My favorite use of sudosh is to do something particularly complicated within sudosh so that it's recorded, and then tell junior admins to go replay the session to see what I did, and in what order.

Ironically, the only system it doesn't seem to compile on yet is OpenBSD (possibly Free and Net as well; haven't checked) - although I hear Todd Miller may be planning to incorporate the sudosh functionality into the sudo code tree.

monsterboard.nl

[SmallFurryCreature]

Of course people make mistakes. Anyone can accidently delete their home directory. BUT good protocol and good people would make the impact minimal. All your local code deleted? Well just recover either from your own backups OR the company backups.

Accidents happen but disasters are made. So get good protocols in place that prevent accidents from turning into disasters.

Simple example, config files for the server. Apache especially can be nasty.

A: Document every change, put the configs in a CVS like system and make sure it clear that nobody can just alter the file.

B: Split it (the firewall idea) into logic parts so that your carefully tuned thread settings are not in the same file as the far more often changed virtual host settings.

C: make sure the editor in question automatically makes backups. So even if the user accidently deletes the contents all will not be lossed.

Now it should be virtually impossible to accidently loose the apache config (wich I have seen happen). Good people do make mistakes but they know how to recover from them.

Perhaps I worded it wrong. I am sure there is some famous quote that says it all.

i can't envision

[weierstrass]

a stampede at the patent office.

No need for root

[jbolden]

The two things you listed you don't need root for.

1) get a file ownership changed
Either you should own the file (because an employee quit for example) in which case the problem needs to be addressed for many files or its specific to this one. If it is specific than
read the file and make a local copy.

2) a specific package installed.
Install to your home directory and share it out. Programs that are shared out that lots of people use will get installed and managed centrally.

A few thoughts

[QuestorTapes]

> ...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.

You already have some replies on the file ownership issue. I suspect if you provide more details, people can give you more tips.

But why do you need packages installed? In a controlled environment, you would normally be working with the versions of various packages that are ordinarily provided, plus a core set of additional packages for development. The only exception I would see to this is if you are doing exploratory analysis of various development tools. In a situation like that, I'd suggest a smaller, separate network for this testing, on which you may have elevated permissions.