Every file and folder in OS X has permissions associated with it, which allow the system to grant or deny access to specific users and groups. You can see these permissions by getting information on a selected file or folder in the Finder, and then expanding the “Sharing & Permissions” section at the bottom of the window.
In this list, the top-most entry is the owner of the file, followed by the file’s default group, and then an entry for all other users. Each of these entries have associated permissions, that allow the relevant accounts either read-only, write-only, or both read and write access to the file.
When set up correctly, permissions can isolate secure areas in OS X such your home folder, or have areas like system folders that are read-only, so operating system files can be accessed but not edited without specific authentication.
Any file or folder in OS X will have a default set of permissions, determined by a special filter called a “umask.” To understand how the umask works, first consider the standard permissions modes for files and folders in OS X, as can be seen by the uses of the “chmod” terminal command.
Unix permissions in OS X
In Unix-based systems like OS X, “chmod” (Change Mode) applies permissions settings to targeted files and folders, and runs with the following syntax:
chmod MODE TARGET
In this syntax, the TARGET is the desired file or folder, and the MODE is one of a number of approaches (numerical is what I’ll cover here) for setting the permissions for the owner, the group, and everyone else. 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
These numbers are applied in sets of three for the MODE in the chmod command, with the first number representing the owner, the second being for the group, and the third for everyone else. For example, the following makes 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
The chmod command changes permissions for existing files, but when you create files, the system applies a default permissions set to files, and this is where the umask comes into play.
The permissions umask
By default, the system will start with full access to a file (7 for the owner, group, and everyone else), but then runs this through the umask filter to result in the final permissions applied to a new file.
To see the umask in OS X, open the Terminal, type “umask,” and press Enter. When you do this, the output will be something like “0022.” The first character in this mask represents a special permissions value called SetUID, SetGID, and “sticky” bit, which offer special modes for running executable files. Since this first character is not too important for everyday tasks, we will ignore it here.
The next numbers of the umask (022) represent the values subtracted from the full-access permissions level for a file (level 7 for the owner, group, and everyone), to result in the default permissions that are given to a new file or folder when you create them.
In a nutshell, the umask’s values of 022 are subtracted from the system’s default permissions of 777, which results in a permissions setting of 755 for the file. This means the owner has full access, with the group and everyone else having only read and execute access for files.
This umask will be applied to all new files and folders created in the system. While the built-in Documents, Desktop, Music, Movies, and other folders in your home directory have custom permissions that keep them private, because of the umask, if you create a new folder next to these in your home folder then its contents can be readable by everyone. Therefore, for privacy, be sure to either change the permissions of files and folders you create in your home folder, or only place them within the existing folders Apple has created there.
Adjusting the umask
Unless you have a specific reason to do so, there is no need to change the system’s umask. In some instances, programs and services rely on the umask to create files that are properly accessible or executable. For instance, many preference files are stored in a binary format that requires executable permissions to be properly set, otherwise they cannot be read.
If you need to change the permissions for a single file or folder, then do so in the OS X information window; however, if you have a reason to have all file permissions changed by default, then you can do so by adjusting the umask. One such example would be if you regularly create custom folders from an area on the boot drive that is accessible by other accounts, and you want to ensure specific permissions for these files.
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:
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 generally runs behind the scenes, it contains a number of environmental settings, one being the umask setting, that can be adjusted in its configuration file.
You will need to create and edit this file yourself for user-specific launchd configurations, so open the Terminal and run 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 — This mask cuts off all access except for the user who created the file or folder
umask 027 — This removes 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.
Topher: Thanks so much for this simple explanation. And I have a question: Remember back in the good ole’ days of System 9? and 8, and, well, 4.1? Users had full access to all System pieces and did no harm (as long as the System folder was blessed, of course).
Along comes OSX and everyone’s in a huge panic over permissions and ‘oh god don’t let anyone at the Library!’ I get the new systems are far more powerful, and far more complex, but still.
Nobody uses this computer except me. I’m not a beginner. It’s connected to my wife’s computer and we have very secure firewall tech for the internet. So why not just run as root?
It’s a serious question. All of the permissions and incessant passwords are making me crazy. Are we over- protecting ourselves?
The prior versions of the Mac OS being fully open made it far easier for malware to work, and yes there were plenty of malware for the classic Mac OS. In addition, in multi-user environments the classic Mac OS was not optimal for this precise reason. Not only were settings hard to keep separate, but documents and personal data had to be manually segregated by the users. With OS X, there is simple, built-in file segregation with multiple accounts, and this approach also makes it easy to implement file sharing and restrictions not only among users of a system, but also to different computers. This integrated networking setup also allows the system to fit nicely into domains with centralized sign-on, with anything from netboot options up to roaming home folders.
Overall, the framework upon which the Classic Mac OS was built was limited, whereas the new OS has far more capability and versatility. That being said, I do miss the old Mac OS interface. It was what made the system a “Mac” to me, and while the change to OS X and Aqua brought a refresh and I love it, it fundamentally changed the interaction that defined the Mac OS to me.
Thanks. I miss it too! But really you didn’t answer the question. For those of us on a single computer with no other users nor network access, permissions and passwords are nothing short of a PITA. I am constantly opening Keychain Access, for example, and it’s really irritating when a simple TextEdit file reports it can’t save to a folder. Or when a Zip file upon opening reports the same thing.
It’s overkill in that situation, adding unnecessary overhead. I’ve gotten to the point that I ignore ownership on all remote volumes in my admittedly lame and poorly informed attempts to simplify daily computing.
The multi-user environment is way cool, I have to admit. So is running lots of apps at once. On the other hand, MultiFinder solved about 90% of my needs. Sad, I know.
The Mac would benefit, I think, from an additional mode, much like the way user accounts can be restricted by parents, or the way Simple Finder worked. When setting up the computer, the user would certify it’s a single user single account, which could simplify the whole thing. Just a thought.
And thanks so much for these pieces. Your efforts are really appreciated out here in user-land. I do an 800 word column for a newspaper every week. But you do several pieces a day. It’s work.
The highest permissions for a folder are “777” but for a file they are “666”. Setting a file to 755 would be pretty bad.
Secondly ugo + – = rex should also be mentioned so you can add a permission vs changing it.
Sorry …. RWX not rex
A permission level of 7 is very often used for a file, as this just enables execution of the file. This is necessary for running scripts and binary files, otherwise when you target the file the system will not try to run it.
For instance, create a shell script called “test.sh” in your home folder by running the command “pico test.sh.” Then save the file and try to run it using dot-slash notation, such as the following:
When you do this, you will get a permission denied error. Setting the permission of the file to 7 enables execution, allowing the owner, group, or everyone else to execute the file properly.