OS X is a multiuser and privilege-based computing environment that sequesters functionality based on various account types, such as administrator and standard accounts. This allows some users to have more system configurability options than other users, but the difference can be a bit confusing to people who are not used to how accounts are set up in OS X.
Apple Discussion user "Daylene" writes:
"I'm a brand new convert to Mac from Windows. In browsing through some threads, I read about not using your computer in admin mode. I'm still learning a lot about using the Mac and had no idea I was using admin mode (at least I think so because I didn't do anything but set up my Mac and register it)."
In OS X, all accounts are authenticated by a local directory ("NetInfo" up through 10.4, and "Open Directory/LDAP" in 10.5) that contains usernames and encrypted passwords, as well as group membership, which is how much of the system accessibility and limitations are assigned to user accounts. The system uses "POSIX" (legacy) and "Access Control List" (modern) methods of assigning user and group permissions to files and folders, and while there can be a variety of account types based on the specific permissions setup for groups to which accounts can be members of, in OS X there are four basic account types:
Managed, or "standard," accounts are the basic account types in the system. Items that belong to the account are sequestered to the home folder for that account, and while the user for that account can create items in shared resources, such as external disks, they are limited by what they can and cannot do in the system based on the privileges given to them. In general, the user will only be able to write to shared resources such as other account drop boxes and external disks. Other resources will have read-only access for managed accounts, such as the Applications folder in which managed accounts cannot add items, but they can open items.
Administrator accounts are set up exactly like managed accounts. They have home folders in the same location and observe the same limitations as managed accounts when running applications, creating files, and other routine tasks. The primary difference is that they belong to the "administrators" group, and therefore can authenticate to change items on the disk that do not belong to them. As such, they can make changes to the system (installing system-wide applications, change system settings, and alter other user's files) if they first authenticate.
It isn't the account itself that specifically has the privileges to alter things, but rather the "admin" group is what holds the capability to change items. As members of this group, administrator accounts just inherit this capability, and this is why any account can be easily promoted to or demoted from administrator status without having to make systemwide changes so a specific account can access resources.
The "root" account is a special account that is set up by the kernel. This account is not an administrator account because it does not belong to the admin group. In fact, it does not need to belong to any groups in order to have privileges to system resources. Instead, it can be seen as the "system" itself. When the system loads and starts the various boot applications before any user has logged in, it runs these applications as the "root" user.
The root user is always running, since this is the system; however, for security, you cannot log in by default, even though this can be done if you specifically enable the root user in "Directory Utility." If you log in as root, you will be running the system as a user that has absolutely no restrictions and can open and edit ANY file on the system. This risks harming the system if you do not know exactly what you are doing.
The "guest" account is a very limited account that can be seen as a temporary managed account. Like standard "managed" accounts, the guest can access all items that it is specifically granted permissions for, but by default when the guest logs out, all items created by it are deleted by the system.
Since administrator accounts are basically the same as managed accounts when running normal computing tasks, there is no harm in running day-to-day activity as an administrator. The only additional risk is if you carelessly supply administrative authentication to tasks, which can be done more easily when running as an administrator than when running as a managed user. This is primarily because the administrator's credentials can be stored in the keychain for that account, and therefore provide easy administrative access to any program you have let access your keychain.
The Bottom Line:
Overall, there is no additional risk in running as an administrator versus with a managed account, provided you are careful with your authentication credentials.
When people say to not run as an "administrator," usually they are referring to the "root" account. Logging in as "root" is exceptionally risky because there are no holds barred for the root account, and as such you can severely compromise your system even through indirect actions. There is no point in enabling the root account beyond temporarily doing so for rare and specific administrative duties that cannot be done by the administrative group. Since OS X does not enable this user by default, you should not have to worry about running in "admin" mode. Just be careful about the programs to which you provide your authentication credentials.
The key here is to be cautious about providing ANY program with your administrative passwords, regardless of what account you are in. Before giving any program your administrative passwords, ensure you trust the program and know exactly what you and the specific program are doing. For the most part, the only time you will be required to input an administrator password is when you install a program.
One final note, since from any account you can authenticate as an administrator, many people will just play it safe and run as a standard account, reserving the administrator account only for installing programs, updating the system, and altering system settings. Ultimately this is the safest way to run the system, but the additional level of safety really only depends on how much you trust yourself with dishing out authentication credentials.Resources