As Mac Adminstrators, we often have to deal with user privileges for files and processes. While doing that we will use administrator privileges and
sudo without as much as a second thought.
However, a proper understanding of what these privileges and processes actually do and mean, can help prevent many problems when managing Macs.
- Part 1: Demystifying
- Part 2: The
- Part 3:
- Part 4: The Authorization Database
macOS is based on BSD Unix, which stems back to a time where large mainframes were so expensive they had to be shared among many users. Users and their access privileges control what any user can read, write, or change in the system. These rules prevent conflicts and data loss or theft. When managing these users and their access privileges, there had to be a first, ‘top’, or ‘super user’ which has access to anything.
In Unix and Unix-like systems this user account is traditionally called
root. In macOS this user is often also called ‘System Administrator’.
Classic Mac OS, in contrast, had no concept of multiple users built-in to the system. Any person sitting down at a Mac (and any process launched on that Mac) could access and change anything on that system. There were some attempts at adding multi-user functionality to classic Mac OS, but they were ‘added on, not built-in’ and fairly easy to circumvent when a user knew what to do.
User and process management was one of the main benefits Apple touted for the various ‘next generation’ systems Apple introduced in the 90s to succeed classic Mac OS. When Apple bought NeXT and with it the NeXTStep operating system it inherited the unix model of doing so.
Even though the concept of sharing your computer is now relegated to some classroom labs and supercomputer clusters, this model still is present in every macOS and iOS device today. On iOS it is completly invisible to the user, unless a jailbreak is applied. On macOS, however, users and especially admins have to deal with it every day.
Users on macOS
To create a new user on macOS you have go to the ‘Users & Groups’ Preference Pane in System Preferences. Before you can add a new user, you have to unlock the preference pane by clicking the lock icon in the lower left corner. Then the system will prompt for an username and password with adminstrative privileges.
When the account you are logged in as has admin privileges, its name will be pre-filled. When the account is a standard user the username field will be empty and you can enter another user’s name and password.
Once the pane is unlocked, you can hit the ‘+’ icon under the user and will be offered four choices for a new user (from the popup menu next to ‘New Account’:
- Standard (the default)
- Managed with Parental Controls
- Sharing Only
There are three types of users not present in the popup list
- System Administrator
- system services users
The difference between Administrator and Standard accounts is that Administrator accounts are members of the ‘Administrators’ or
admin group. This sound simple, but membership in this group bestows many additional benefits.
In day-to-day use Administrator accounts and Standard accounts behave the same. However, there are many situations and workflows on macOS which require authenticating as an Administrator account. As a general rule, a user can affect all the files (and applications) in their home directory and in
/Users/Shared, but as soon as you want to change another user, another user’s files or settings that affect all users on a system you need to authenticate as an Administrator account.
The first user created on an unmanaged Mac out of the box will always be an Adminstrator user. Most Mac users use an Administrator account. Many of the workflows built-in to macOS assume an adminstrator account. One example is setting up a new printer.
With an Administrator account you can install third party software. You can also install malicious software. Often malicious software will trick users into installing by masquerading as or hiding in an installer for something useful.
Many consider it a ‘best practice’ to run your everyday work on your Mac with a standard account and only use an administrative account when you have to. However, since you get prompted to authenticate even with an administrative account, the better advice is to take these prompts very seriously and consider what confirming this prompt will really do or install.
The only difference you get when using a standard account is that you need to enter a different username and password in an authentication box instead of just the password. If this helps you pause and consider what you are actually doing, then great! Then this is the proper workflow for you.
However, I suspect that most users would be just as non-considerate of this dialog with a separate username and password as they would otherwise.
macOS Administrator Accounts
The only difference between Adminstrator accounts and Standard accounts is the membership of the
You can check whether a given user is a member of the
admin group with the
$ dseditgroup -o checkmember -u armin admin yes armin is a member of admin
You can also use this tool to add or remove a user from the
$ dseditgroup -o edit -n . -a username -t user admin # add username $ dseditgroup -o edit -n . -d username -t user admin # add username
This membership comes with many privileges. Admin users can (after authentication):
- unlock System Preferences and change system settings
- install Apple and third party software and installer packages
- create, change, and delete files owned by other users
- change access privileges and ownership of files of folders in Finder
- run and stop (kill) processes owned by other users
and many things more.
On macOS these privileges are controlled mainly by two mechanisms:
- the authorization database
sudo is used to gain root privileges in the shell (Terminal). The authorization database controls access privileges everywhere else.
root can do
The ‘System Administrator’ or the
root account controls the system. Mainly the root account can read, update, delete all local user accounts. It can control file and folder privileges and ownership. It can start system services running in the background and assign system network ports (with a port number lower than 1000). Most of this is managed by a process called
launchd which is the first process to run on macOS.
Many commands require to be run as
root or with elevated
root cannot do: System Integrity Protection (SIP)
On macOS, however, there are limits to what the
root account can do. System Integrity Protection is a mechanism which protects important parts of the OS from mnodification, even with
Only certain processes signed by Apple are allowed to modify these protected files and directories. Usually this means Apple signed installer pkgs for software and security updates.
Apple lists a set of top-level directories that are protected. However, the list is a bit more detailed. You can use the
-O (capital letter ‘O’, not a zero) to see if a file or directory is protected by SIP:
$ ls -lO /usr/ total 0 drwxr-xr-x 978 root wheel restricted 31296 Mar 30 18:21 bin drwxr-xr-x 294 root wheel restricted 9408 Mar 30 18:21 lib drwxr-xr-x 238 root wheel restricted 7616 Mar 30 18:21 libexec drwxr-xr-x 8 root wheel sunlnk 256 Dec 28 13:48 local drwxr-xr-x 248 root wheel restricted 7936 Mar 30 18:21 sbin drwxr-xr-x 46 root wheel restricted 1472 Mar 30 18:21 share drwxr-xr-x 5 root wheel restricted 160 Oct 3 2017 standalone
Files and Folders marked with
restricted are protected by SIP. Sometimes folders inside a protected folder may not be protected, as the
/usr/local/ directory in this example is.
SIP provides more protection than just certain parts of the file system, it also protects changing the boot volume and some other aspects of the OS.
While these limitations on even the
root account can be annoying, they provide a level of security that parts of the OS have not been tampered with or changed by other software.
Enabling (and Disabling)
On macOS the
root account exists with a UID of ‘0’. However, it is set up so you cannot log in to a Mac as ‘System Administrator’ or
root. (A terrible bug in early 10.13 provided a brief exeception to that rule.)
Note: login as
rootis disabled for security purposes. It is highly recommended that you leave the
rootaccount disabled on macOS and rely on
sudoto gain temporary super user privileges when necessary.
If, for some reason, you do need to log in as
root, then you can enable the
root and provide it with a password. You can do so in either the ‘Directory Utility’ application. After unlocking with your administrator password, you choose ‘Enable Root User’ from the ‘Edit’ menu. You can also change the root account’s password here or disable it again later.
From the command line, you can also use the
will enable and/or update the
root account. It will interactively ask for admin credentials and for a new password for the
root account. Read the command’s man page for details.
$ dsenableroot -d
will interactively disable the
root account again.
Different environments and tools have different means of gaining super user or
root privileges. While the
sudo command should be the preferred means of gaining temporary super user privileges, it is important to know and understand the other options.
Scripts and tools executed from LaunchDaemons run as root unless a different user is specified in the
UserName key in launchd property list.
LaunchAgents on the other hand will be executed as the user logging in.
You can get details on how to set up and use LaunchDaemons here.
root in ARD
When you prepare a ‘UNIX command’ to be sent to remote computers in Apple Remote Desktop, you have the option of running the command as the currently logged in user or as a specific user. When you specify
root as the user, the script will execute with super user privileges. Since the ARD agent process runs as
root on the client, no extra authentication or enabled root account is necessary.
The agent software of most management systems (Jamf, Munki, etc.) is installed to run with
root privileges. Therefore, scripts executed by management systems run with
root privileges as well.
Installation packages also perform their task with root privileges. They also require administrator authentication to start. Any installation scripts (
postinstall scripts) will also run with
There is a special bit you can set on an executable’s mode (or privileges) which tells the system to run this script as the file owner, no matter who actually runs the executable. If the executable file is owned by
root it will run with
This flag is the “set-user-ID-on-execution bit”, also called the “Set-User-ID”-bit or just “s-bit”.
In the long
ls format or with the
stat command the set-user-ID bit is shown as an ‘
s’ in place of the user’s
x bit. One example is the
$ stat -l /bin/ps -rwsr-xr-x 1 root wheel 51200 00:57 /bin/ps
chmod's u+s to set the set-user-ID bit and
u-s to remove it:
$ chmod +x importantcommand [rwxr-xr-x] $ chmod u+s importantcommand [rwsr-xr-x] $ chmod u-s importantcommand [rwxr-xr-x]
Warning: Obviously it is very important that this executable is not modifiable by other users. They would be able to replace the command with their own code and execute anything with root privileges. Most system commands that have the s-bit set on macOS are protected with SIP.
As mentioned before, the recommended way of gaining super user privileges from the command line in macOS is the
sudo command. The name means ‘super user do’ and will perform the following command with root privileges after verifying the user running
sudo has the permission to do so.
We will look at the
sudo command in detail in the next post.
- Part 1: Demystifying
- Part 2: The
- Part 3:
- Part 4: The Authorization Database