Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Root 101 - Concept of Root for Newbies

Posted by timothy on Thu Feb 27, 2003 12:22 PM
from the to-bookmark-for-friends dept.
Operating Systems Software Unix
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.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Root 101 - Concept of Root for Newbies 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • CLI (Score:2, Insightful)

    by TheCrimsonUnbeliever (638597)
    It is the CLI of unix that gets people every time - there is no way to explain that it is generally easier to do stuff through a cli

    ifconfig for example - I can rememeber the ifconfig line for any computer on my network and have it in and done in seconds

    But in windows it takes a few minutes just to click click click

    • Re:CLI (Score:2, Informative)

      by Anonymous Coward
      the 'netsh' command in Windows will give you the equivelant functionality of ifconfig at the command-line. you can run it in interactive and script modes, too. the downside is that it's slower than ifconfig; the upside is that changes made here are permanent, whereas command-line changes in ifconfig don't persist across reboots.

    • Re:CLI (Score:3, Insightful)

      by suwain_2 (260792)
      Precisely! I constantly field questions from people on why I insist on using programs in 'DOS,' and how Linux is SOOOOO outdated because of this. What they don't get is exactly what you said: if you know what you're doing, it's often times 10x easier to just type in the command than it is to point-and-click through illogically-oriented menus. (I'll admit, if I have no clue what I'm doing, a GUI helps...)

      Sometimes the command line can save even more time, not just because you don't have to search poorly-layed-out GUIs for the option you want. For example, the other day I got really sick of having about 50 "incomplete" MP3s in my playlist. Rather than going through and deleting all the files one by one, I fired up Cygwin (which gives you a shell on Windows... quite handy!) and did "rm __INCOM*" to delete the countless files beginning with "__INCOMPLETE__" Nice and handy.

      Not to mention the remote access aspect of the command line. I'm responsible for maintaining a webserver running Linux; it's so handy to be able to pull up an ssh session and do whatever needs to be done. Let's see the admins of the Windows boxes neighboring it work on their servers from home.

      Anyway, I may have just bored everyone to death, but for those just getting into Linux/UNIX, don't fear the command line! If you take the time to learn it, you'll grow to love it.

      • Re:CLI (Score:4, Insightful)

        by joshuac (53492) on Thursday February 27 2003, @05:11PM (#5400756) Journal
        ---snip
        Not to mention the remote access aspect of the command line. I'm responsible for maintaining a webserver running Linux; it's so handy to be able to pull up an ssh session and do whatever needs to be done. Let's see the admins of the Windows boxes neighboring it work on their servers from home.
        ---snip

        It's not difficult to setup ssh on windows, and redirect the io of cmd.exe (or most any other CLI shell available for windows, come to think of it) through it if you know what you are doing. The problem isn't so much the OS, it's the type of admins the OS attracts. 90% of windows "admins" do not know how to use the cli and cli apps included with windows, or even use many of the graphical management tools included to their full extent.

        With NT 5 native RDP support was added, although you have been able to make any NT machine support RDP for awhile now, (assuming you do not need multi-user support; in that case your stuck with their terminal server distribution, or purchasing something re-written by Citrix and dumping RDP for their protocol), and with NT 5 they made a telnet server an official part of the distribution (not that I would suggest using it). Of course, you could do all this years ago with NT 4 as well...(and with NT 3.5x with a little adaptation, probably).

        BUT...do many NT "admins" know how to do this, or even have the slightest clue about where they would go to get started? Nope. And from what I have observed, in more than a few places having a _little_ more knowledge about the OS they "support" would have made their lives a lot easier...but they don't bother, they just keep slogging on with what little knowledge someone force fed them at a certification class.

        Unix admins on the other hand tend to actually take an interest in knowing what makes their OS tick. Partly that the OS is much more open (for some Unix OS's, you can even get the source code easily). Partly that in the Windows world, the interface to a server appears identical to the interface to a workstation, which gives confidence to users who want to become an admin where they deserve no confidence at all :).

        A good admin can make up for a weakness on any platform, whether it be Netware, Linux, Windows, or Lantastic, without needing to blame his/her tools. A lousy "admin" can also more than compensate for all the strengths of a platform. What matters most is the competency of the admins that tend to work with those systems, not really the systems themselves.

        That all said, given a choice, I know which platform is takes me much less effort to secure than the others...heck, you might almost say it is "secure by default" :)
          • ---snip
            but in my experience, trying to manage windows from the command line is a horrendous task.
            ---snip

            For sure, different OS's are more or less admin-friendly. But difficult is not the same thing as impossible.

            Trying to manage windows from the CLI _is_ a much more difficult task than with most other OS's. However, with the right tools you can manipulate the registry database, kill or start a process, manipulate files, or just about anything else you would need to do. In any practical real-world situation you would not hassle yourself with trying to work that way, unless it were a task particularly suited to the command line (automation) or you were in a situation where a CLI was all you had available; remote admin of windows machine is almost always done in a GUI (although many of those GUI tools can be ran locally to manipulate a server remotely over a network).

            A good admin _can_ accomplish all the same things, but too often people say "it cannot be done" out of ignorance rather than fact.

            Woodworking is a hobby I am just starting out on. Ask me to make a particular type of joint with certain tools, and I will say it is impossible. Ask that of someone who has been working with wood his whole life and knows what he is doing, and he can make it happen. I said the tools were not capable of it, but in fact, it was me.
          • Yes, you *can* admin a win2k domain from the command line. Even if you don't write in perl or {insert scripting lang here}, you have the resource kit available to you for all sorts of remote admin tasks.

            A couple of links:


            Hope this helps :)
        • I think you still need to do:
          del ___INCOM*.* actually
            • Renaming files is one of the things that doesn't seem to be standardised on.

              Many distros include a program called "rename" that takes a regular expression search-and-replace type expression and uses perl to rename files passed to it accordingly.

              For example:
              rename s/^10/20/ 10*

              For example for your first example.

              rename s/^(..)10/\120/
              for the second.. and so on.

              It does seem that some distros don't provide this program by default, and you might have to install it yourself tho. Even worse, there is a another rename program that doesn't work anything like this floating around.

              Hope I've helped a bit...
        • Hehe, I realized after I posted it that it wasn't a very good example... A better one would be the more complex pattern matching that can be done, or the easy scriptability. (Okay, again, DOS can be scripted... *needs to stop pointing out these bad examples*)

      • Re:CLI (Score:2, Funny)

        by akamoe (519034)
        What makes us more advanced then cave men is language. Try explaining how to do something by pointing and grunting and you will see what I mean. For somethings like moving a rock from one place to another that might be sufficient and probably even easier but telling someone how to build a cart out of 2 wheels would be imposible with out language.

        You've obviously never managed a McDonalds.

        --R

  • misleading capabilites of root (Score:5, Informative)

    by teridon (139550) on Thursday February 27 2003, @12:29PM (#5397361) Homepage
    The article says that only root can "Start and stop background processes". Any user can do that, but only root can start and stop processes belonging to other users. Perhaps that is what he meant?

    • Re:misleading capabilites of root (Score:1, Insightful)

      by Anonymous Coward
      He probably meant 'services' instead of 'processes'. Like things in /etc/rc.d/init.d for example. Starting stuff like network interfaces, system loggers, daemons can only be done by root.

  • Not a good idea ... (Score:5, Insightful)

    by Khalidz0r (607171) on Thursday February 27 2003, @12:34PM (#5397423) Journal
    I think if this is directed to newbies then it shouldn't contain information about "how to get your root password".

    Well, if someone needed it they'll know how to search and find out, but then, stating it right away in a "beginner" introduction only brings interest to script kiddies to *hack* the password.
    If you use the information below to bypass security on a computer you're not supposed to be messing with, you're probably committing a felony.
    That's more of an eye opener than a warning.

    Thanks for reading,

    Khalid

    • Re:Not a good idea ... (Score:3, Interesting)

      by Xformer (595973)
      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...
      • The fact that they have short memory doesn't mean you tell em (oh it's easy to get it back so never mind about caring about the password).

        Telling a newbie that they SHOULD do something right is way more impoortant than telling them the WRONG alternative.

        There are many cases where machines are physically accessible by script kiddies, one would GO search for a unix-based PC just to "root" it after seeing this, I know many people who would.

        I just don't think it's the right place to put such info.

        Khalid

        • I put this in the piece because I forgot my own password once, when I was first learning to use Linux. A buddy set up the machine for me, configured it, and I basically just played around on the command line. When I actually began to want to do things, I found I had forgotten my root password. Luckily, my buddy knew it, since he had set up the machine

          My belief is that if we want to make Linux a viable alternative to Windows for garden variety users, we have to demystify it. This means giving them the tools to save themselves if they make mistakes.

          We can't have it both ways. If we want people to use Linux, we can't keep them in the dark about the ins and outs. This means those of us who have boxes sitting around need to make sure they're physically secure. Both grub and lilo have password options...

  • Making a master key (Score:5, Insightful)

    by DeadSea (69598) on Thursday February 27 2003, @12:41PM (#5397509) Homepage Journal
    Too bad that it doesn't tell you how to escalate your priveleges from user to root the same way that you can escalate your priveleges to master key in your apartment building using your apartment door key.

    That would be really worthy of Slashdot.

    The one thing that appears to be missing is the section "Why shouldn't I run as root all the time if I'm the only one using my system." In your house (comparing your single user system to your house) nobody can control you like a puppet. Somebody can't move your arms and legs and force you to take a sledgehammer to the hot water heater. If you are running Unix as root, any code that you run could make you do just that. It's worth protecting yourself against virii by not running as root.

    • Re:Making a master key (Score:2, Informative)

      by skookum (598945)
      By the way, that paper (referenced in Schneier's last Crypto-Gram) about privelege escalation with physical pin tumbler locks is here [crypto.com].
    • move your arms and legs and force you to take a sledgehammer to the hot water heater. If you are running Unix as root, any code that you run could make you do just
      that.
      Wow. If malicious code on my computer can make me do anything it wants me to do, including destroying household appliances, I really should be a security paranoid.
    • The one thing I have *never* understood about not being root to protect yourself against viruses is that I don't care about the system files I only care about my personal files.

      How does not running as root protect me from that?

      • And it protects your from finger slips, and your friends telling you its really cool to type in "rm -rf /".

        If you are a person that is reading about root and how to get it, you are probably the type of person that is willing to figure out what you should and shouldn't do to your system. If you have a bunch of users you trust, I'd think that would be a good argument for why you shouldn't give them root.

  • interesting analogy... (Score:2, Funny)

    by Anonymous Coward
    ...but at my shop, everyone enters the building using the concierge's key (administrator), a copy of which is conveniently taped to the front door. (Post-It [TM] to the monitor). We have not, however, gone so far as to include the password in our Telnet greeting -- you'll have to sniff for that yourself.

    Um, yeah. Hey! NTFS has default journaling and no 15-minute filesystem checks!

    Proudly serving Satan since ought-two.

  • Sudo (Score:4, Insightful)

    by aridhol (112307) <klacquement@gmail.com> on Thursday February 27 2003, @12:46PM (#5397580) Homepage Journal
    The comments on sudo are almost correct...

    When you use sudo, you will be asked for a password. But it's your own password, not the admin password. Also, you'll have to be configured with sudo access to run the command you're requesting. And your admin will be emailed if you try to do something you're not allowed to do.

  • root vs. Administrator (Score:4, Insightful)

    by magickalhack (648733) on Thursday February 27 2003, @12:58PM (#5397731) Homepage
    This piece deserves a companion article: what Microsoft did wrong. It is utterly impracticle to use anything other than an Administrator account when running windows (despite the vulnerabilities this leaves you open to) because over half of the useful programs out there, including many titles by Microsoft itself, require Administrative access unnecessarily. The breakdown of privledges is much more distinct in the *nix world. Windows has a long way to go.
    • True, but more for Applications than just programs. Office, Photoshop, etc. all run fine as a normal user. But try running the Age of Mythology demo in Windows 2000 as a normal user; you'll get a message box stating you have to be an admin.
      An admin...to play a game!?

        • Re: Age of Mythology (Score:3, Informative)

          by MeanMF (631837)
          One thing that would be nice would be some sort of suid functionality, so I could tag a file to always run as a certain user no matter who it was executed by. That way I could selectively trust certain applications

          I think you can do this (on XP) with the RUNAS command.. Something like:

          runas /user:administrator /savecred <program>

          Throw that into a shortcut, enter the password once, and you're all set. Don't ask me where it's storing that password though.....
            • Apparently it only works with XP Professional, so if you're running the Home edition you're screwed.. Also I've been playing around with it a little more, and it looks like once you save the credentials, you can launch ANY program with the runas command without reentering the password.

                • Re: Age of Mythology (Score:3, Informative)

                  by MeanMF (631837)
                  You can't use the "Run As" option on the shortct properties.. You have to use the command-line RunAs.exe utility with the /savecred parameter every time you're launching the application. So you might do something like:

                  runas /user:administrator /savecred "c:\program files\Internet Explorer\iexplore.exe"

                  The first time it would prompt you, but after that it would just load. You have to put that whole command line into a shortcut if you want to launch it from an icon or the start menu. You can nest quotes inside the command line with a backslash - I use this on a shortcut to launch the ISA administration console:

                  runas.exe /user:domain\administrator /savecred "c:\windows\system32\mmc.exe \"C:\Program Files\Microsoft ISA Server\MSISA.MSC\""
    • As often, the problem lies in backwards compatibility with windows 9x, which had no multi-user support (profiles don't count) and thus spawned programs which presumed to be able to write wherever they want.
    • 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..
      • That's called a fork bomb, and it's more efficient if you coded it in C (not really much more work, and hey, it 'runs out' of memory faster). An endless while() loop with malloc() works wonders too :).

        ulimit (in bourne shells) and limit (in C shells) can protect the machines from resource starvation attacks like these. In FreeBSD (and probably other BSD's as well, I've seen it in BSD/OS (a.k.a. BSDi) too) at least you can hardwire limits into the user's environment with the classes system and login.conf. Do equivalents for Linux exist?

    • What Microsoft did right... (Score:4, Insightful)

      by hoegh (306704) on Thursday February 27 2003, @02:44PM (#5399080)
      ...was to see that users like my parent couldn't care less about security. Anything that hinders them in doing what they want to do is considered a nuisance.

      I am also having a hard time explaining to my wife why I have revoked most priviliges for the "Internet zone" in IE (yes, I prefer Phoenix too, but the sad fact is, that there are many sites that won't work unless you use IE) - somehow it is still to much of a bother to add sites that we trust to the "trusted site" list the first time we visit them.

      Maybe you just need to get burned once to respect fire (and of course understand what happened). Within the first 48 hours of my job as a student programmer I managed to wipe all files of several projects - my current directory wasn't what I thought is was and I had become more priviliged than I should be. That day I learnt not to invoke all priviliges in the login-script but only as needed. I also learnt something about proper backup routines that day - the nightly backup really saved me (thank you dear sysadmin for saving my from the wrath of my colleges...!).

      Oh - that reminds me of another story. As student programmers we were given group-privileges (this was VAX/VMS). It was very practical to be able to start and stop job on behalf of other student programmers etc. Once one of the other student programmers wrote a utility that would log you out every interactive session wherever you where logged in (which was rather handy when someone asked if you would like to come along for beer). The utility stopped all interactive processes that it could find, but the author remembered to explicitly turn of our group priviliges before doing so, so we didn't accidentially log each other out. Somehow our sysadmin got hold of this utility and since it was throughly tried and tested by us for several months, he trusted it. One crusual difference between a student programmer and a sysadmin is that a sysadmin has world-priviliges and the script didn't turn these of...! He learnt the hard way that as a sysadmin you should trust noone.

      When we asked above mentioned sysadmin for more privileges ("can I have oper-privileges so I can restart this print-queue?!?") he always answered "Do you want more responsabilities?" No, we only wanted more privileges. "Well" he said "it is the same thing - do you still want your privileges?" Somehow it wasn't really nessecary with more privileges anyway. And that is perhaps one of the most useful lessons to be learnt.

  • MacOS is simpler than that (Score:3, Informative)

    by andfarm (534655) on Thursday February 27 2003, @01:07PM (#5397850)
    You don't really need to restart your machine to set up the root account under OS X... there's a menu option in one of the NetInfo configuration apps to "Enable root account". Much easier than rebooting the machine, heh.
    • You don't really need to restart your machine to set up the root account under OS X... there's a menu option in one of the NetInfo configuration apps to "Enable root account".

      Not to spin off-topic or anything, but it's actually easier than that.. open a terminal with an administrative account and type "sudo passwd root" set root's passwd, then su up and party.

      -matt

  • Kludge? (Score:4, Interesting)

    by Hard_Code (49548) on Thursday February 27 2003, @01:14PM (#5397951)
    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? (Score:2, Insightful)

      by martyros (588782)
      Well, even in systems like LIDS which have controls even on root, there are still ways to gain privileges to do things... in other words, there is the need for a super-super-user. The basic problem is that people make mistakes, and things are buggy. What happens if a user accidentally takes away his own access to a file? What happens if the MAC or capabilities get screwed up somehow -- either because of end-user error, or some glitch in the system? Until we can guarantee this won't happen (i.e., probably never) you need the ability to come in and play 'God', so to speak, to set things right.

      What's a kludge is giving some random process complete superuser access, when all it needs to do is just one thing -- i.e., modify /etc/passwd, or bind to port 80, or access /dev/tape to do a backup. That's what MAC and capabilities are for.

    • Re:Kludge? (Score:3, Interesting)

      by digitalmuse (147154)
      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.
      • Installing obscure libs and new versions of perl can be done in ~/lib and ~/bin. It can also be done for a whole group in ~/../groupname/lib or ~/../groupname/bin if you've set up your home accounts as /home/groupname/username with a group writable directory at /home/groupname/groupname.

        Set your system-wide bash/login scripts to properly reference these paths, and not only do you no longer need to su for these problems, but you don't even need to sudo. Users can do this for themselves. Its a booteeful thing.

        You can run unix machine for a long time with the root password in a vault, if you really lay things out correctly.
    • One of the original Unix architects, in one of the earliest papers about Unix, said flat out that the concept of having one ultra-privileged user violated the precepts of good security design.

      The principles it violates are least privilege and separation of powers. Sudo helps take the curse off. So do features like the append-only file attribute -- even root can't erase a log that shows bad actions by root if the log file is append-only (have to boot to single-user to clear that flag).
    • Not really.

      At some point, you have to have the `top' user who is able to grant all other users various priveliges, and to change all other users' passwords when they forget theirs. Call that user `root'.

      Once you have that user, it's possible to write a program which, when run as that user, creates a new user with a known password or changes an existing users password to a known value, imbues them with whatever priveliges you _do_ want if it doesn't have them already, changes to _be_ that user(*) and then executes whatever code you actually want to execute.

      However you cut it, you have to have a user with `top' control. If you pretend that that user doesn't exist, you will lull users into a false sense of security when they are running as that user.

      If you make people aware that `root' can do anything, if you tell them to be scared of it, tell them to set up `sudo' and use it as much as possible because otherwise their system will get hosed, then they have a chance.

      If you pretend otherwise, then that's just inviting disaster.

      K.

      (*) You could do this either by a `setuid'-type function, or setting up a program to execute on login and then arranging a login, or a whole bunch of other ways.

  • new slashdot motto (Score:2, Funny)

    by Anonymous Coward
    Slashdot: news for clueless newbies. Stuff that makes you think you're a l33t ninja hacker.

  • Next on up... (Score:5, Funny)

    by smoondog (85133) on Thursday February 27 2003, @02:16PM (#5398737)
    Next we can try more difficult tasks, like explaining command mode in vi.

    -Sean

  • You know what I want? (Score:4, Insightful)

    by Anonymous Coward on Thursday February 27 2003, @02:34PM (#5398959)
    I want to use Linux. I want to use a command line. I want to know how to add and remove programs. I want to know how to add and remove hardware refences in the kernal. I want to know how to access my data. I want to know what programs are on my system, and what they do. I want to find programs that do specific tasks. I want these and a whole lot more. And I want it all in an easy to UNDERSTAND reference guide.

    I know everyone says "Switch to Linux! It's more powerful and stable then Windows, and it free!" But I have tried several times to switched, and everytime I do something goes wrong. I can't get the sound to work. I can't get my network card to work. I can't get the proper video drivers installed. I can't get it to boot up properly. Whatever. And everytime, I install Windows, spend an hour or two setting up my programs and getting everything, and I'm done. I'm using my system. I have never had that with Linux.

    Basically, I want a Linux system that's as easy to install and use as Windows. I would love to learn how to use Linux properly. But I can't seem to learn it. And I've had to learn how to use an AS/400 system. Even that was easier to do then learn Linux. And I'm a programmer. It's not like I'm some dumb schmuck who thinks Windows is the best thing in the world. So until you can give me a Linux system that I can learn, or give me a better way to learn it...then you'll have problems getting the mainstream users.

    • Well, I never asked you to switch to Linux. Linux/UNIX as a primary OS is for the experienced. If you want to learn, give it a try and spend the time to get experienced. If you're too unmotivated to figure it out, don't bother. It takes time to learn these things. You have to give Linux/UNIX at least 6 months of solid use before you can even call yourself a beginner. It will not be easy, no one said it would. But in the end you will be more comfortable in this environment then you ever were in Windows. You'll feel the true power as you will be able to do things that are effortless to do in Linux but nearly impossible to do in Windows.

      I want to use Linux. I want to use a command line. I want to know how to add and remove programs. I want to know how to add and remove hardware refences in the kernal. I want to know how to access my data. I want to know what programs are on my system, and what they do. I want to find programs that do specific tasks.

      Sounds like you want to give Debian a try.

      Also, Linux is not the only OS you can try. Try a *BSD or even OS X.
      • Hear hear! Get a Mac, run OS X, do as much as you can in the terminal, and then drop into the GUI when you really get into a bind.

        From my experience, the only way to learn this stuff is to do it. Make mistakes. Buy a book or two, search the web for the stuff you don't understand, and make some really good hacker friends. Buy them caffeine.
  • In many systems, there is no concept of the almighty root, but there is the administrator. IIRC VMS has limited-rights administrator (dunno about Windows). This is a good thing in environments where you can't/mustn't fully trust even the administrators.

    Really, root is one of the disadvantages of UNIX.

  • Just wanted to let everybody know that the "Root 101" [iodynamics.com] article has been updated on the Iodynamics [iodynamics.com] site. Most of the revisions are based on the comments above.

    I appreciate all of the great feedback, both here and via e-mail. This article has truly been a community effort.

    --Dave

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.