Super User

A SuperUser in Unix is a computer system god, someone who can break any and all rules governing mere users.

The SuperUser is not to be confused with a PowerUser, which refers to someone who knows a lot about running their system or systems, and is comfortable exploring further, but doesn't code at all, or enough to be a full-fledged hacker. Also, a PowerUser is still a regular user compared to the SuperUser. PowerUsers and regular users have similar privileges, while the SuperUser can do anything.


The following "discussion" is in desperate need of refactoring. Although there is a lot of information there, a lot of it boils down to: "Unix is crap because it's so unforgiving of mistakes" plus insults.


In Unix, you need a user account which can ignore all bits of protection in the file system to accomplish certain tasks such as:

The MicrosoftEquivalent? is the user named Administrator

In PlanNine, there is no equivalent. Ordinary users can mount a filesystem into your namespace without arbitrary limitations. And raw access to a device requires raw access, not some ad hoc "super user" account.


The abilities of the SuperUser don't tend to be nearly as granular as they need to be. Why should I be able to, for example, delete the entire file system if all I need to do is open a listening socket below 1024? Several operating systems attempt to factor the abilities into more discrete granularity. VMS is quite good at it. Data General's B2 secure UNIX shoehorns those abilities into UNIX. There is also some work being done in the Linux kernel - the abilities are there but there's not a whole lot of user interface into them yet.

LIDS (http://lids.org) can limit SuperUser privileges in Linux.

Generally speaking, you should never run as SuperUser. Never ever ever. The number one mistake all new UNIX users make when they get their own UNIX box is to run as SuperUser, despite the 30 years of UNIX SysAdmin experience dictating that you should never run as SuperUser. The response is inevitably the same, "I know I'm taking a risk but it's my own machine and I know what I'm doing." You can't argue with that person, you have to let them learn through cruel experience. After they rm -rf * .txt from root a few times or get owned by skript kiddies, they usually wise up. - BruceIde

And of course, the users are right in their demands. If it's possible to delete the filetree without immediately undeleting it, then that is Unix's fault. If it's possible to make any kind of irrecoverable operation, then that is again Unix's fault. You are right only to the extent that Unix absolutely sucks and people, necessarily, must make extensive allowances when working in such a horrible system.

Yup. That's the problem with unix, all right. It sucks. Unfortunately, to take a phrase from Churchill, it sucks less than basically all the other options at this point (which are nearly zero, unless you a) don't care how esoteric/expensive your hardware is, b) write all your software in-house.).


Note that BruceIde's advice "you should never run as SuperUser" above should not be taken to mean that you should never use the SuperUser account. You have to use the SuperUser account for certain administrative tasks; that's why it exists. But you should only use the SuperUser account when you need to do something that an ordinary user cannot. Never get into the habit of logging in as root just to use the system. -- BrentNewhall

I once had to log in as root to restore the /home partition from backup. Don't recall exactly what I managed to screw up, but screw up I did. And of course, there was simply no reason for it.

Sure, there was a reason for it: You made a mistake. One of the reasons for the existence of the SuperUser is to recover from human error. -- BrentNewhall

What a load. The only reason for the existence of superuser is because Unix is so horribly dangerous, it needs constant supervision by trained monkeys to keep it running. And since Unix is insecure as all hell, there are plenty of operations (like copy and move, to say nothing of remove!) which can't be allowed to proceed except by mythical Nietschean Ubermen. Thus, normal users are stripped of any power to do their work and the superuser gets absolute, totalitarian power over all creation.

To make copy, move and remove actually usable, you'd have to make them reversible using versioning. Nobody does this, preferring instead to engage in victim bashing; "it's your own fault", "you made a mistake", "you should learn better", blah blah blah.

Consider, just what does installing software or creating user accounts have to do with administering the hardware? These are user operations belonging in the user domain. And they do, in UNIX. I install software as a regular user all the time. Now, to place it in the standard locations requires SuperUser action, but that's just to keep out the BlackHats who would replace ls with malicious code. "Installing" software means making it accessible to all users. (No, it doesn't. A user can install software that's accessible to only that user or certain users.) Can you do that in Unix without malicious users replacing the critical user-installed FooBar application? Is there any granularity or is it an all-or-nothing shit deal? And if you say you have versioning, my next question is who controls the symlink that points to the latest version?

Software installation and user account creation apply to all users, though. Do you really want any user capable of changing any part of the system? Do you want everyone to have access to /etc/passwd? -- BrentNewhall It's not an either-or question; either users can't change the system sanely, or every bozo can change everything. And the reason why is because of a feature called "computer security"; a feature Unix lacks completely.

There is no good reason for SuperUser. For that matter, there's no good reason for PlanNine's "null" user. There is no justification whatsoever for any hardcoded class striation of users.

Of course, it is trivial to convert a Unix system so there is no user hierarchy. I have used several configured this way. On the other hand, in the RealWorld(TM), often a system is mostly *used* by trained monkeys, not administered by them - and as such, they have to be restricted in their ability to harm themselves. Either that, or someone has a full-time job cleaning up after there (repetitious) messes. Not that I am a big fan of Unix itself, but I doubt you can point to a system in large-scale use today that doesn't have at least as many fundamental problems. I certainly haven't seen one (more's the pity).

I don't see why one has to be able to point to a commercial alternative in order to bitch about Unix. The whole point of bitching about Unix is to raise awareness so that Something Gets Done and a commercial alternative becomes possible.

And I disagree that it is "trivial to convert a Unix system so there is no user hierarchy". Attempting to do this to Unix would leave it either unusable or insecure, or both. Of course, it may not seem that way because Unix is already unusable and insecure, and people are used to this deplorable state of affairs.

In addition, the same consideration applies to every computer system because a user hierarchy is both inevitable and desirable. We can only avoid making this hierarchy rigid by hardcoding it. We can have a flexible and fluid hierarchy where the number of users, their interrelationships, and the powers accrued to them are not limited by arbitrary restrictions.

For example, it should be possible for user A to have administrative powers over user B, who in turn has administrative powers over user C and so on in a chain of arbitrary length. It should also be possible for user A to have power over user B* and both users B and B* to have power over user C, without either B or B* having power over the other. It should be possible for a user to have any kind of combination of power over and access to resources.

All of these require a hierarchy, and a system which has "no user hierarchy" is entirely useless as a result. As proof, I present MS Windows.


EditText of this page (last edited May 21, 2004) or FindPage with title or text search