This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Toor" Unix – news · newspapers · books · scholar · JSTOR (February 2026) (Learn how and when to remove this message) This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (February 2026) (Learn how and when to remove this message) This article relies largely or entirely on a single source. Relevant discussion may be found on the talk page. Please help improve this article by introducing citations to additional sources. Find sources: "Toor" Unix – news · newspapers · books · scholar · JSTOR (February 2014) (Learn how and when to remove this message)

toor, the word "root" spelled backwards, is an alternative superuser account in Unix-like operating systems, particularly BSD and variants.^[1]

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.

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.

The presence of a 'toor' account (or the presence of more than one account with a user ID of 0) 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 (arguably misconfigured) security program.