Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Please see the (somewhat) related topic here.

My day-to-day tasks on a linux machine require superuser access since I would be (re)starting services, monitoring the system, (un)installing stuff etc.

Some time ago, I was insulted/ridiculed in an IRC session (as to be expected), because I was logged in as root to install ruby.

Apparently, it is normal* to install services while being root, but not the services to function from a root account. This is understandable - you don't want access violations in, say, apache, to allow root privileges.

*which contradicts the awesome people on IRC......go figure.

So the main question, I guess, is why do install instructions for many services (as of late, seen it on nodejs, ruby and cloud9ide), assume that you are not root when installing them?

For example, only last week, I installed cloud9ide but couldn't get it to work since it specifically prohibited me from running it as root. Yet, no one nowhere mentions anything about it. I've fixed this issue by running:

su -s /bin/sh apache -c "node /var/www/cloud9/server.js -l -p 3131 -w /var/www/html"
share|improve this question
I'm not sure how your question isn't a duplicate of that one. – mfinni Jul 13 '12 at 14:51
@mfinni That person asked the difference between sudo/su and actually logging in as root. My question is about how people install things that require root for installation, but not for running. – Christian Jul 13 '12 at 14:56
In hindsight, you're correct - there is a difference in your question. – thinice Jul 13 '12 at 15:09
Installing software as root is fine, and you'll have to do it. But why on earth were you using an IRC client as root? That's the part I can't figure out here. – Michael Hampton Jul 13 '12 at 17:27
@MichaelHampton I don't think he said he was running IRC as root. He was installing Ruby. Just sayin'.. – Aaron Copley Jul 13 '12 at 20:30

In addition to the reasons already mentioned;

In an environment large enough to have multiple system administrators for a single host or group of hosts, sudo allows for accountability that sharing the root account does not.

share|improve this answer
This is an excellent point. – Mike Purcell Jul 13 '12 at 20:54
I think that's a very fair point, but in my case, there's only one administrator - me. – Christian Jul 13 '12 at 23:22

As you have realized certain things require root privileges. When you need them you should use them.

It is perfectlty fine to use root when you know what the commands you are running will do, and that the won't have any unexpected side effects.

Downloading software for the Internet and compiling it is potentially dangerous. It could be buggy, or have intentional harmfully commands in it. A makefile might have an rm -rf command in it for example. Or perhaps some other part of the build script has some unknown bug that would wipe out your system. This same reasoning can equally be used to encourage you to not compile un-tested software on production systems. You should be building and testing packages in a testing environment where it doesn't really matter.

You could follow a simple checklist when exercising your root privileges. If you can't answer yes to a three of these items, you probably shouldn't be using root.

  • Does the command require root privileges
  • Do you completely understand what the command will do.
  • Do you have backups or the ability to undo if/when something breaks

So in a virtual machine, that you just took a snapshot in you can probably get away being very indiscriminate with your root privileges. On your a production server holding many critical services you would need to be far more cautious about your usage of root privileges.

Like everything related to security it is all about the level of risk. You have to make an intelligent determination about the potential risk compared with the amount of effort/reward. There are places where you should almost never by using root, and there are cases where using root to compile things probably has no risk associated with it.

share|improve this answer
I pretty much agree to the points you mentioned. In addition, I should have mentioned that my root-related issues stem from experience of a VM. I always run such things on a VM before on a production system. That, however, does not alleviate the problem about software that expects to run under a different user but does not say so in its installation instructions. While I'm not a "copy and paste" person, I think a huge "this software must be run as a different user" warning would be welcome. – Christian Jul 13 '12 at 23:28

The instructions are trying to assume the readers should follow implicit 'best practices' which entails not being logged in as root.

These types of tutorials/instructions have a part of their target audience that just copy-pastes the commands, or have enough knowledge to create a real mess.

It's important to condition beginners to follow these best practices for their own protection (and feelings if they go on IRC).

There are things that are certain in this regard:

  • Everybody who uses root directly will fat finger a command and it will mess something up in bulk at some point. (That's not to say 'sudo' users are immune, just less likely, and there can be limits imparted on such damage).

  • Majority of users who ignore best practices and end up fat-fingering have no clue how to undo their new mess.

  • Said user will likely approach a help forum or IRC channel asking for help and thus be ridiculed for being root in the first place.

share|improve this answer
Why exactly is running sudo yum install test safer than just yum install test? While at it, let me highlight an important line in my question... – Christian Jul 13 '12 at 15:30
Because running sudo yum install will put that single command in as root. Whilst running yum install as root would do the same thing- are you really telling me that you would sudo/su to root, run a single command, and then come back out? Hence, why to run a single sudo command. – AliGibbs Jul 13 '12 at 15:41
I think my explanation was lost: It's safer because the day will come when you screw up a line. When that day comes, you'll be glad there's an extra layer of formality, many people confuse that with inefficient or a burden as you seem to indicate. – thinice Jul 13 '12 at 16:41
I should add, your own experience with this question:… (I'm under the assumption that was run as root) should be more than enough explanation as to why the extra layer of formality is helpful. – thinice Jul 13 '12 at 16:47
@thinice I still do not understand the point in this concept. In that question, for example, I would still need to run the command as root since the directory I need to remove fell under root anyway. While I don't deem sudo inefficient at all, I do see it as an extra burden in an environment which I need to manipulate only as root. – Christian Jul 13 '12 at 23:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.