Understanding default permissions in OS X
Creating new files and folders gives them a default permissions set that can allow access to them from other account, which may be concerning at first glance.
The home folder in an OS X account is intended to be off limits to all but the owner of the home folder; however, if you create a new directory immediately within your home folder, and not in any of the default subdirectories, you will find that other user accounts can peruse the contents of this new directory.
This may be concerning to some people, as outlined recently in an e-mail to me by MacFixIt reader Patrick:
"I am admin on my Mac; it runs under OS 10.6.8 Snow Leopard, and I just created a user account for my girlfriend. I obviously expect my files to be hidden for her, but that is not the case. She can just open the Finder, go to Macbook/Users/, pick my name and see what's in there. Some folders are protected, but [custom ones I create] aren't. It's strange that folders I created in my Home folder should be visible to others."
It's true that, by default, the contents of accounts in OS X should be kept secure from other users. However, while it may seem odd, this behavior seen is, in fact, normal, given both the way that permissions are set up in the user account and how the system applies default permissions to files and folders. So why does this happen?
Every file and folder in OS X has permissions associated with it that allow the system to grant or deny access to specific users and groups. If used correctly, permissions can isolate secure areas such as user home folders, or have areas like system folders that are read-only, so the operating system can be accessed but not easily tampered with.
When you create any file or folder in OS X, it will have a default set of permissions that give it a certain level of access by the owner, the default group (from the account that created it), and then "everyone else." This default permissions setup is determined by something called a "umask," which applies a special permissions filter to files when they are created.
To understand how the umask works, first consider the standard permissions modes for files and folders in OS X.
In Unix systems, a commonly used command-line tool is "chmod," which stands for "Change Mode" and applies permissions settings to targeted files and folders. The chmod command is run in the following way:
chmod MODE TARGET
In this command, the "TARGET" is the desired file or folder, and the MODE is one of a number of approaches for setting the permissions for the owner, the group, and everyone else. Classically, this is represented by numbers between 0 and 7, which mean the following:
0 -- No access
1 -- Execute Only
2 -- Write Only
3 -- Write and Execute
4 -- Read Only
5 -- Read and Execute
6 -- Read and Write
7 -- Read, Write, and Execute
In the "MODE" for the chmod command, these numbers are applied in a series of three consecutive values, with the first value representing the permissions for the user, the second for the group, and the third for all others (everyone), such as the following to make a file called "test.txt" fully accessible (7) by the owner, read only (4) by the group, and no access (0) by all others:
chmod 740 test.txt
While chmod is useful for changing existing permissions, what sets up the initial and default permissions that the system applies to new files? That is where the umask comes in.
What is the umask?
When you create a file or folder in OS X, the system initially does not know what permissions it should set, so it attempts to apply full read, write, and execute access (number 7 shown above), for the user, the group, and everyone else. The system then adjusts this behavior by using the umask as a filter to reduce the default mode values from "7" for the owner, group, and everyone else, to a more desired value for security.
If you open the OS X Terminal and run the command "umask," you will see an output of the current mask value that likely looks something like "0022." The first "0" in this mask represents a special permissions value for something called a SetUID, SetGID, and "sticky" bit, which offer special modes for running executable files. This first "0" is not too important for everyday tasks (and we'll ignore it here), but the next three values, "022," are the permissions mask for the owner, group, and everyone else, respectively.
Being a mask, these values do not represent the permissions level, but instead are simply subtracted from the initial full-access permissions level (level 7) to result in the default permissions that are ultimately applied to newly created files and folders.
This means that with the system's umask of 022, the permissions of 777 will be adjusted to 755, which by the table above shows that the owner will have full access, with the group and others having only "Read and Execute" privileges. If the umask were 000 instead of 022, then no change in file access would be applied, and if the umask were 777, then all permissions for everyone would be stripped, and new files and folders would only be accessible by the root (system) account.
This umask will be applied to all files and folders created in the system, be they in a public area or a private area. Since the only folders in your account that have truly private permissions setups by default are the Documents, Desktop, Music, Movies, and other built-in folders, if you create a new folder next to these, then the system's umask setup will make it at least readable to everyone. In fact, the files and folders you create within the Documents and Music folders (and other default directories) have permissions that also technically make them accessible by others; however, the more restricted permissions of the Documents and Music directories themselves serve as the block that prevents access.
Can you change the umask?
For most purposes there is no need to change the system's umask, especially since there are some instances where programs and background services may rely on specific permissions to access files properly, some of which are set up by the umask (for instance, a binary preference file's requirement to be executable by its handling program, regardless of the user account under which the program is run). However, in the vast majority of cases this restriction applies to system processes, and not to those in the user account. Therefore, while changing the umask globally can lead to problems, adjusting it for user-run processes can sometimes be beneficial.
There are multiple levels in OS X where you can apply a custom umask, some that are more global than others. In the OS X Terminal you can use the umask command itself to change the umask, such as the following to make the umask 011 instead of the default 022:
This will have the effect of making all new files and folders readable and writable by the default group and "others," but the scope of this change will be limited to the current Terminal session. If you close the Terminal and reopen it, then the default umask of 022 will be reinstated. Similarly, the Finder and other programs will not be affected.
If you have a special situation where you would like to change the umask for the system, then you will need to do so for the system launcher (launchd).
Launchd is the umbrella process under which all system processes run, and under which each account and corresponding programs run. This setup allows for sequestering of resources at different levels for security and stability. While launchd is generally run behind the scenes, it does number of environmental settings that can be adjusted using a configuration file, one of which is the umask setting. Changing the umask at the launchd level will have it apply to the Finder, and other applications that you run in your account, instead of being limited to the Terminal.
To apply the umask to the launchd process, you will need to create and edit a user-specific launchd configuration file, so open the Terminal and do so with the following command:
sudo pico /etc/launchd-user.conf
Note that the name of this file has "-user" in it, specifying that it will only be used for the umbrella launchd process for each user account. Without this in the name, the "launchd.conf" file would apply to the global launchd process, which could adversely affect the system.
With the editor open, type in the command "umask" followed by the desired filter setting on a single line. Some common options are the following:
- umask 077 -- Cuts off all access except for the user who created the file or folder.
- umask 027 -- Cuts off all access for the "everyone" group, leaving the default group with read- and execute only privileges.
- umask 007 -- This allows the default user and group full access, but cuts off all others.
When finished, press Control-O to save the file, followed by Control-X to exit the editor. Now simply log out of your account and back in, and the launchd configuration will incorporate the new umask settings.
The umask is responsible for custom folders in your home folder being initially readable by other user accounts, but though adjusting the umask can be done, it is not necessarily the appropriate fix. If you have a single folder in your user account that is accessible by another account, simply get information on the folder and adjust its permissions to prevent all but your account from being able to read and write to it. However, if you regularly create and delete custom folders from your home directory or from another area on the boot drive, and wish them to be relatively isolated regardless of where they are, then adjusting the umask might be a more appropriate course of action.