A lot of people use the root account to do anything they need, just because it is easier…
This is a really bad idea, as that user can do anything to the system. Not only can he access/delete/modify any file and its permissions, but he can mount/unmount filesystems, kill/start/stop processes, add hardware to the machine, stop the machine, create/delete semaphores/pipes, … and all that even wiping out any evidence of the modifications applied.
Annoyingly, there is no real practical way of disabling the root user on a Unix system.
All that can, of course, be done even without the actual user knowing or willing it (a virus or another harmful script/program executed by root could do anything it wants).
Many times, people use the root account to compile programs. The problem is that most of the time, they don’t even check the makefiles, which could be really harmful. They should instead compile everything with another user, and only change to root to do the final make install.
An even worst idea is to allow remote or graphical connections using it. If someone (or something, like a virus) directly logged remotely as root, there isn’t any way to know who it was in fact. Forcing the logging as another user instead, and changing to root afterwards at least ensures the bad guy has to crack at least two accounts (root and a user). Moreover, when you know that the user account has been compromised, you can disable it, not root.
The problem is often just that the user has already done a lot of things as root and it would represent a lot of work to revert the rights and permissions on files to a regular user and/or test if everything works as user. It is a never-ending loop. We highly recommend you do not try to go further in that direction. Take the time to fix all this, your system will become much safer.
It might seem easier not to manipulate the permissions to exactly match what you need, especially when several people need to read and modify them. But in the long run, this is clearly not a solution.
sudo might be a practical solution to the problem.
This article was first written in October 2003 for the BeezNest technical website (http://glasnost.beeznest.org/articles/86)