Back to Basics: Unix File Permissions
Posted: February 17th, 2010 | Author: charlie | Filed under: Linux / Unix | Tags: education, linux, Security | 5 Comments »The most basic, yet important part of mastering Unix is to fully understand the nuances of file permissions. Tools exist to manage permissions easily, but true enlightenment and quick troubleshooting skills come to those who wholly master the concept. Remember, 80% of Unix problems are permissions issues.
The Concept
At the most basic level, there are three types of access:
- Read – the ability to open a file and read it
- Write – the ability to write the file
- Execute – the ability to execute (run) the file
Directories, though similar, are subject to special rules. Write permissions on a directory imply that you can create new files and directories within. Execute permissions are required to ‘cd’ into the directory, and read permissions are required to list the contents (‘ls’).
You will generally see permissions represented as r, w, or x; for read, write, and execute. Running ‘ls –al’ on the command line will show three sets of these strung together.
For example: -rwxr-xr-x
The dash means that the permission is not set. The first place is always reserved for special identifiers, like ‘d’ for directories or ‘c’ for character devices. The next place begins the actual permissions, for the user, group, and other categories.
Every access control in Unix is based on “who you are.” The user is identified by the uid (user ID), as defined by a person’s user account. The third field in the /etc/password file, for example, specifies what a user’s uid is. Similarly, every user belongs to a default group, as identified by the fourth field in the passwd file. Users can belong to many groups, but they’re always a member of their default group.
The above example of -rwxr-xr-x means that the owner of the file may read, write and execute it, the group members may read or execute it, and everyone else on the system may also read or execute the file.
A full example, from the output of ‘ls -l’ is:
-rw-r–r– 1 charlie root 164 2006-12-10 23:51 test.js
The file named test.js is owned by me with read and write permissions, is set to the root group who can only read it, and also allows everyone else to read it.
How it Really Works
That’s basically enough to get by, but being able to understand the more advanced modes of file permissions, your umask, and the numeric representation demands a full understanding. In reality, there are 8-bits available for each type of attribute. Take a look at Figure 1 and note that wherever you see a 1 in the binary column, a corresponding permission will exist.
| Number | Permissions | Binary |
|---|---|---|
| 0 | --- | 000 |
| 1 | --x | 001 |
| 2 | -w- | 010 |
| 3 | -wx | 011 |
| 4 | r-- | 100 |
| 5 | r-x | 101 |
| 6 | rw- | 110 |
| 7 | rwx | 111 |
As you can see, if a “bit” in a certain position of the binary representation is set, the permissions in that space are activated. The number column is the octal representation, and the “Binary” column is how it really works, from the operation system’s perspective.
Example time. Let’s say we wish to give ourselves read/write/execute permissions, the group read/execute, and everyone else read/execute permissions. The following commands both do the same thing:
- chmod u+rwx .; chmod go+rx .
- chmod 755 .
Since we know that setting ‘5’ means rx, we can simply say ‘5’ instead of ‘rx.’ The real advntage to knowing the octal representation is that we can set any arbitrary permissions with a single command. Running the chmod command using the mnemonic requires that we run it each time for each set of permissions.
Likewise, to set our umask, we must know how the permissions are numerically represented. The umask is the default mode with which files and directories will get created. It’s a mask, so if we want to create all files with permissions like 755, we must take the mask. Simply subtract 7 from each item, and 022 reveals itself as the magic setting. See the umask man page for further details.
Advanced Modes
There are, in fact, three other modes you can set on a file or directory. All Unixes support the following:
- 4000 set user id (suid) on execution
- 2000 set group id on execution
- 1000 the sticky bit
If suid is enabled, the permissions look like: -rws——
This means that when the file is executed, it will run with the permissions of the owner of the file. It’s dangerous, but some times necessary and quite useful. For example, a file suid and owned by root will always run as root.
When sgid is enabled, the permissions look like: -rwxrws—
When set on a directory, sgid means that all files created within the directory will have the gid set to the current directory’d gid. This is handy when sharing files with other people, who will often forget to give other members read or write permissions.
The sticky bit looks like: -rwx——T
When the sticky bit is enabled, only the owner of the file can change its permissions or delete it. Without the sticky bit, anyone with write permissions can change the modes (including ownership) or delete a file. This one is also handy when sharing files with a group of people.
There are other tidbits of information, once you get into the nuts and bolts of Unix file permissions too. For example, you can also set ACL attributes, which get horribly complex. Yes, you can give individual users access to your files, but it’s better not to. Creating a new group and sticking to general permissions can accomplish most things. Often the extended attributes aren’t necessary, and ACLs likely won’t work over NFS if you’re using Linux.
Spend some time with the chmod manual page to master tricky parts, if they still aren’t clear. It will also mention some implementation-specific limitations you may need to be aware of.
5 Comments »
Related posts:
- Back to Basics: Unix System Stats Utilities
- Back To Basics: Unix Differences in Performing Tasks
- Working With Unix Variant Differences
- Multi-user Security in Linux
- The Perils of Sudo With User Passwords











The chart you give shows binary 3 as 110 and, as I am sure you know, it should be 011. That being said, I now have a clear understanding of file permissions. Thank you.
Just checking to see if people were paying attention! Ok, it was a typo – thanks! (fixed)
Thanks for the follow on Twitter. See how it drives traffic to your blog?
And while we’re being all nitpicky here, it’s “octal” not “decimal” and “mnemonic” not “pneumonic.”
The stuff about 4000/2000/1000 bits was enlightening. I admit that I’ve limited my application of permissions to the 777 discussed in the first half of this article.
The sentence “Often the extended attributes aren’t necessary, and ACLs likely won’t work over NFS if you’re using Linux” raised a few questions in my head, to wit: 1) What are some useful use cases and real-world purposes for the extended attributes? 2) What’s an ACL? 2a) Are they similar/different to the Access Control List concept in OpenVMS? 2b) While we’re on VMS, why is there no “D”elete bit in the Unix permissions and what’s the use of it in OpenVMS when a user with “W”rite can simply truncate a file, effectively erasing it? 3) What (typically) goes wrong with ACLs via nfs?
That said, I tend to run Linux on personal machines, in developer environments where everybody on the box has sudoer access, or where files are all buried beneath a tangled web of network application software, so it might as well be like DOS permissions for all the practical good it does me.
Hi Charlie,
Yes, I love Twitter; and you’re certainly right about the nitpicky corrections, thanks
Extended ACLs are extended attributes (permissions) that can be applied to most POSIX file systems. NFSv4 ACLs are a whole different beast, and the two don’t always jive. Say you have an NFS server running Solaris and files with extended ACLs. Linux will not see those at all. NFSv4 server to NFSv4 client (if they are all Linux) works, but that’s the extent last I checked.
Real world: say I want to give a friend/coworker access to a file. I either open it up to the world or must be in the same group as him. With setfacl, you can just grant him read access to that file or directory. Also, default ACLs are super handy. Instead of hoping collaborators understand umask, you can enforce a mask that ensures files written to a shared directory are group-writable. I wrote an article about group collaboration (but focused on Samba), here:
http://www.linuxplanet.com/linuxplanet/tutorials/6844/1/
In Linux/Solaris, see: setfacl(1), getfacl(1)
(if Ubuntu, you must have the ‘acl’ package installed)
Sorry, I don’t know anything about VMS.
You’re absolutely
right!