3

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 192.168.1.117 -p 3131 -w /var/www/html"
Christian
  • 485
  • 6
  • 24

3 Answers3

5

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.

Aaron Copley
  • 12,954
3

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.

Zoredache
  • 133,737
1

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.

thinice
  • 4,746
  • 23
  • 38