In Unix, it is traditional to keep the root filesystem as small as reasonably possible, moving larger programs and rapidly changing data to other, optional parts of the system. This increases the likelihood that the system can be brought to a semi-usable state in the case of a partial system failure. It also means that the superuser account, necessary for repairing a broken system, should not depend on any programs outside of this small core. To this end, the root account is often configured with a shell which is small, efficient, and dependable, but awkward for daily use. The toor account is intended as a solution to this problem. It is identical to root, but is configured to use a different, more featureful shell. Alternately, toor may be configured with the emergency shell, allowing root the freedom to use the featureful one.
Implementation
In a Unix-like system, each user has a user ID number, which is what the kernel uses to distinguish users and to manage user permissions. User ID #0 is reserved as the superuser account, and is given permission to do anything on the system. Users log in by username, not by ID number, and a user's choice of login shell is also managed by name. This separation between name and number allows a given user ID to be associated with more than one username, each having its own shell.
Security considerations
The presence of a 'toor' account triggers a warning in many security auditing systems. This is valuable, since if the system administrator did not intend for a second superuser account, then it may mean that the system has been compromised. It may be argued that even an intentional 'toor' account is a security risk, since it provides a second point of attack for someone trying to illicitly gain superuser privileges on the system. However, if passwords are chosen and guarded carefully, the risk increase is minimal. For example, NetBSD ships with a disabled 'toor' account, meaning that there is no password with which one can log into the system as 'toor'. This is not a security risk in itself, though it may generate security warnings as previously described. However, if the system is compromised, an administrator may be less likely to notice the enabling of a disabled account than the creation of a new one, especially if they have become accustomed to ignoring warnings about 'toor' from their security program.
