Root 101 - Concept of Root for Newbies

Fozz writes "One of my colleagues wrote this article explaining the concept of root/super user for Unix newbies. He wrote it after looking for information like it and not finding much. His analogy of Unix and an apartment complex is one of the best metaphors I've seen for understanding multi-user OSes." If you're running any variety of Unix, you've probably been forced to learn this pretty well already, but this is a very lucid explanation to point out to curious friends / co-workers who aren't so sure.

Comments

Re:Not a good idea ...

[Xformer]

If a user's machine is physically accessible by a cracker or script kiddy, then any security you may have is already gone. All of the techniques stated in the article require that kind of access.

The reason it's in there in a newbie article is that newbies can have the habit of a short memory when it comes to passwords and the like. This I know from experience...

Kludge?

[Hard_Code]

Not to start a flame fest here, but isn't a single 'superuser' entity, which has special-case security (e.g. has automatic ownership and access to all files regardless of permissions), indicative of a mis-designed security architecture?

What about capabilities, or mandatory access controls? Or some sort of framework that incorporates root privelages, instead of setting them aside as a special case. I've never been comfortable with the idea that the security system was only for "normal" users and didn't apply to a specific user called 'root' (or id 0), which, if compromised, you are entirely hosed.

Re:Kludge?

[digitalmuse]

One thing that I have had pounded into my head by all the great unix geeks who have taken the time to lead me down the path of linux enlightenment is that 'root' should be viewed as the last resort for most tasks. With some sensible configuration of 'sudo' and permissions management, I can do 90% of my 'admin' tasks without having to login as root. Your users can handle all their own files, copy, move, ftp, grep and do almost 100% of their day-to-day work with just their user permissions. ("users cannot abuse privliges they do not have". - anon. unix admin.)
When someone comes by and says that they need a new version of perl, or they would like you to install some lib that they need for some project, _that_ is when you break out the 'su -' and take off the kid gloves.
I've had a couple of people tell me that you only should need root access when something is seriously b0rken, it's not how you login to check your mail, logs, or grip the squid logs for porn.
As an extended metaphor, I drive my car (a user interaction) and can go under the hood to top off the fluids, change filters, etc. (sudo-ish stuff, simple interactions) by myself, but if I need to install new cams or take off the cylinder head, I leave that to my mechanic (root) who has the larger knowledge of what everything does and how to perform intricate tasks that are beyond day-to-day maintence and require complete control of the system.
I'm not going to say that there aren't risks with having a user account that bypasses the entire security model of a complex multi-user environment, but I think that on a machine which is run/maintained by a knowledgeable/responsible admin the functionality of 'root' in complex circumstances far outweighs the risk of having the account comprimised.

Re:root vs. Administrator

[dougnaka]

Process accounting and restricting would also be a nice default on Linux. I was winning CTF at Defcon last year when people found out this lil jewel... perl -e 'while(1){fork();}'
last thing I saw was no more file handles...
This is roughly as bad as having administrative privileges on Windows..

Re:CLI

[Anonymous Coward]

not any more... not for quite a while actually, possibly back to win98 in fact.

One thing I do still use windows for, as I've not figured out how to do it easily in linux yet (anyone?) is if you need to rename part of lots of files... eg:
ren 10*.* 20*.*
or even
ren ??10*.* ??20*.* ...if ya follow.