Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Root 101 - Concept of Root for Newbies 110

Posted by timothy from the to-bookmark-for-friends dept.
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.
This discussion has been archived. No new comments can be posted.

Root 101 - Concept of Root for Newbies More

Root 101 - Concept of Root for Newbies

Comments Filter:

  • 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.
      • Last time I checked Windows had a command shell too. "del __INCOM*" isn't that hard I suppose.. ;-)
        Cygwin is really nice though..
        • 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*)
          • > (Okay, again, DOS can be scripted...

            Well, yes. But what a big difference there is!

            In DOS, a handful only of commands are available, without any easy way to find out what those commands are (think "tab completion" here), pipes are a childish toy in comparison to the way Unix shells work, there is no `backquote`, and the batch language is a minimalistic version of BASIC which can probably do a lot, but not as much as sh(1).

            It's not about "the ability" to write scripts. It's all about the way those scripts can be written, the number of available tools that can be used in scripts, etc. etc.

            --
            • err...

              cmd.exe /?
              cscript.exe /?

            • What I can't get over is why they chose a backslash to delimit directories instead of a slash. Make me a foe: Anybody who owns two keyboards with backslash in the same place.

              The cd command works funny if you're changing drives, ie from A: to C:, and this whole concept of different "drives" is studpid.

              Yikes, I'm offtopic!

      • 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" :)
        • I'm not claiming to know anything about using CLI to do administration on windows machines, but in my experience, trying to manage windows from the command line is a horrendous task. It seems like the text commands were the afterthought and simply hacked together so that they can claim to have them. Is this just my inexperience showing through?
          • ---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 :)

  • 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.
      • I don't think that's entirely accurate. It's true that only certain ports (0-1023) are reserved for privileged processes, but any user can start a background process that interfaces with the network, performs logging functions, etc. And even so, users can access some of this stuff via sudo.
    • Yep, that's what I meant. All of this feedback has been great. I'll probably do a revision of the article tonight and repost in on Iodynamics [iodynamics.com].

  • 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...

          • I agree, there's no point in witholding this information thinking that we'll be secure because of that. I haven't needed to do this (yet) but I found out how to and remembered so I can get into (my own) system in a pinch.

            To not print this information, on the grounds that it arms script kiddies a way in is only, *ahem* /stands up on soap box security through obscurity. Mind you, if you forget your openprom passwd on a Sparc, let it be known, it is possible to come back, but you've got a problem, so sending the message that it's very important to remember the passwords is a Good Thing.

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

      by Anonymous Coward
      If your site security is so bad you're worried about a how-to text describing how newbies can obtain their own root password, I feel justified in disregarding your opinion in this matter. Honestly, you're recommending security through obscurity, which is never a good thing. Not only that, but the information you're objecting to is so basic that I can't help but wonder if you're serious.
      • You should not state stuff like this in a newbie introduction website still.

        It would serve (for some poeple) as a -how to hack Hotmail through social engineering?- guide.

        A real hacker would already know this and it is no problem with them, but a I-wanna-be-a-cool-hax0r script kiddie type would just find this a good tool for damage. Hiding it might not be right, but still it shouldn't be along side with an introduction.

        I am against the place where it is mentioned, not against mentioning it as a whole (of course).

  • 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.

    • 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.

      Not only that, but in your own house you know better than to hit your water heater with a sledge hammer, unless you know what you are doing.
      On computers, the people who this guide is written for do not know better, and as such, shouldn't do it
      • 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.

    • 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?

  • 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 ) <ka_lac@hotmail.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!?
      • Amazingly enough, that's the exact title that promped my most recent ire. You see I, like many a fellow geek, serve as my family's network/computer administrator. I have a young brother. My young brother likes to get into things he shouldn't. Thus we have blocking software, because my mom wants it. Okay whatever. However, in order to let him play that stupid (Microsoft!) game, I had to give his account administrative access. Not only does this permit him to accidently fuck something up, but eventually he will figure out how to kill the blocking software. Mmmrmph!!! This makes me a frustrated geek. 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. It would also be a useful way to lower a program's permissions, if you usually run as Administrator, but a particular untrusted program has no need to do so. Hmm. I wonder how hard this would be to implement. *goes off to ponder code*

        • 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.....
          • I've tried that but it wants the password every time. If you've done this, can you provide more details on exactly what I might be doing wrong?
            • 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.
              • I can't imagine there are many /.ers running XP Home! ;-) However, I've approached this from every angle I can and I'm still not seeing any way to save the credentials. Even if you tell it to always run as user X it will prompt for user X's password every time. Even saving the credentials would be more safe than what I'm currently doing. Can you illustrate how you did that?

                • 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\""
        • eventually he will figure out how to kill the blocking software

          It's not like blocking software isn't trivial to bypass even with a guest account.

          • -1 Troll :-P

            It's also "trivially" easy to boot from a CD and change the Administrator password. But only your dedicated hacker has such a CD. Security doesn't need to be air tight (which is good, as that is not possible), it only needs to be reasonable for the task at hand.
            • Only dedicated hackers would have a Windows install disk? :-). Besides, it doesn't take a lot of effort to search Google for "cgiproxy".
              • First of all, a windows install disk won't help you if the default security settings are left alone. AFAIK, by default it still requires the admin password to use the recovery console. Anything to the contrary was just a very popular (but false) rumor. And, yeah, it does if Google is blocked. :-P
                • I guess you're right, but you could reinstall the OS with a blank password. That's not very subtle though. :-)

                  And holy fucking shit, do the blockers block Google these days? I know they'd been restricting images/cache, but taking out the main google web search would just be crazy.

    • 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.
      • Well, there is certainly a level of ease-of-use necessary for any general access system, there is not a direct correlation between features and complexity. It just happens to work out that way a lot because more features require a whole lot more work to render easily usable.

        I'm going to bring the other flame magnet into the discussion here and present MacOS X as an example of a system that is very easy to use, but has a lot of functionality that can be unlocked if you want/need it. In fact, if I could afford a new toy right now, it would be a mac laptop of some flavor just 'cause I'm so enamored with BSD...er, OS X. :-)
    • Yes, quite a few programs "require" admin access unnecssarily, especially certain games [blizzard.com].

      It's a shame, but since most (home) users don't know the difference, they accept this, and run as a local admin.

  • 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
  • It's a good analogy - the first time I saw it was in a book by Cliff Stoll called "The Cuckoo's Egg", which was released in 1989 [loc.gov].

    -- R

    • Hmmm. Didn't find that one in any of the research for this article. I actually wrote it because I couldn't find a really good online source that explained root for newbies.

      I also like the metaphor another person here used to explain things. Anything that could be done from a driver's seat can be done under a user's login. If he wanted to change a battery or top off fluids, he would use sudo. If he needed to do major engine work, he'd log in as root.

      • I wasn't trying to torpedo you :)

        I agree that the apartment building analogy is a better one, and I found it odd that in 14 years,
        I'd only ever seen it used twice by people other than myself (including you).

        I can't quote it for you by verse, but it was alot to do with timesharing (IE: "everyone complains about slow service and exorbitant rents" is an exact quote), but he mentions that each tenant shouldn't be able to infringe on any of the others, and how one person could be doing one thing in thier space (writing email), and another in thiers (downloading recipies).

        -- R

        • There was another comment on this piece about an admin who had his root password on a PostIt taped to his monitor. (Of course, why the PostIt was taped when it should have been self-sticking is another topic for discussion. Maybe it had been there for a while and the sticky stuff had all worn of. Anyway...)

          I like the way the analogy still holds up. The building superintendent taping the master key to his door. (Or leaving it on top of the mat.)

          • True.

            Like the accounting server at my 2nd-last job.
            It logged in automatically as LocalAdmin for PCAnywhere, but never locked the console. Ever.
            The all-knowing Accpac server.
            *shrugs and shudders*

            -- R

  • 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.
    • Learning Linux was very difficult for me as well. The single thing that helped the most was having an extra working computer on the net that I could use to contact friends who use linux and access The Linux Documentation Project [tldp.org] from. It takes a lot of patience and perseverance to become proficient with any *NIX CLI... however learning Linux/GNU can be really rewarding. My advice: pick up a cheap 266MHz (or akin) machine you can use to figure out Linux/GNU on, before you try to use Linux as your primary desktop system.
    • You should really check out Knoppix [knopper.net]. This is a version of Linux that boots directly off of a live-CD, auto-detects all your hardware and boots up to a Windows like user interface (KDE), without you having to do anything. Learning a bit more about Linux from there should be pretty easy.
    • I don't suddenly decide I'm going to install Linux on my new PC that came with Windows. I plan for Linux before I get the hardware.


      Linux supports most hardware, but I've been burned before so I always check before I buy. The most likely problem if you buy new is hardware that isn't yet supported in Linux. The WinModem was the most aggravating of these. At the time I accidentally got one of those, I didn't know such things existed (and Linux didn't support them at the time-- too new) so I didn't know to check. The manufacturers made it hard to tell a WinModem from a real one without opening the box.


      The way hardware is added to the PC is horrible. Plug and Play helps, but is really a bandaid. How is the hardware identified? Configured? Allocated resources to avoid conflicts? Used? There is still no standard way of handling these issues outside of Windows.


      Most manufacturers provide a Windows driver (which is usually buggy-- never use the driver that came on the included CD, first check their web site for updates) but Linux is left in the cold. Consequently for new hardware there can be a delay of months before dedicated Linux driver hackers finally manage to wangle the necessary details from the manufacturer or reverse engineer the Windows driver or something. Manufacturers tend to fear intellectual property theft too much to be very cooperative.


      Don't be too hard on Linux-- sure, Linux needs improving, but problems aren't always Linux's fault. Didn't Bill Gates once complain he was tired of Windows (in the days of version 3.1) getting blamed when some poorly written device driver caused a problem? That was a big motivation behind Microsoft's efforts to take over the work of providing drivers. Remember the bad old days of DOS when each graphics application had its own stable of video and printer drivers and configuration issues?

  • Within a UNIX system, root is the God. What piece of this concept requires explaining? 8-)
  • 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.

  • On my Debian systems, rebooting in single user mode when I have lost my root password would be of no help at all: to enter the single-user shell, I need to type the root password!

    If I ever loose my root password, my only way to recover it is to use an emergency boot disk, booting the kernel with a ramdisk whose image is on another disk, with no root password, mount the / on my harddrive to /mnt and edit the /mnt/etc/passwd file to reset (clear) the root password.

    That's why I keep boot disks for each of my systems, and update them whenever I change my kernels due to new hardware, or simply because I upgrade to a more recent Linux version.

  • 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

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close