File permissions are core to almost everything you do on your Linux machine, from viewing a PDF to saving an image and running an app. The core model keeps things simple, but there are quite a few basic details to get started with.
Permissions Control What You Can Do With a File
Most of the time you'll deal with permissions, it will be when you're trying to save or read a file. Every file ( technically, every inode ) has a set of permissions attached to it. These determine whether you (or any other user) can read from a file or write to it.
If you don't have permission to read a file, you'll see an error when you try to open it. Likewise, a file without write permission will cause errors if you try to save to it:
Permissions Come in Three Sets of Three
Permissions have two parts: an action and a set of users. The three actions—read, write, and execute—define what can be done to a file, while the user sets define who can do it.
Every file on your system has an owner and a group. This means you can have one of three relationships with a file: you're its owner, you're a member of its group, or none of the above.
So, when it comes to permissions, there are three sets of three, and any combination is possible. Your file might be readable by everyone, writable by nobody except the owner, executable by members of the group, and so on.
Their Labels Can Be Cryptic
You'll often see permissions shown as a string of 9 characters, like this:
This is an abbreviation that shows the status of the three permissions for each set of users they apply to. It includes, from left to right, the read, write, and execute status for the user, group, and other, respectively. A letter means the permission is set. A hyphen means the permission is not set.
It's important to remember that "o" stands for "other," not owner. This is easy to forget; try remembering that "u" must mean "user," then the meaning of "o" is easier to deduce by elimination.
Breaking the above permission string down into its individual sets gives:
This means the owner of the file has complete control, other members of the file's group can read and execute it, while every other user can only execute it.
You Can See Them With the ls Command
The easiest way of viewing file permissions on the command line is to use ls, the command to list files . By default, ls will show just file names, but the -l option displays files in long format, which includes permission details:
You should be able to spot the string of permissions characters right at the beginning; they're the nine letters in between the leading "d/-" and the trailing "@" at the start of each line.
You Can Also Use the stat Command to View File Permissions
While ls is the easiest way to view permissions, stat is probably the best. The stat command is like a lower-level version of ls, one that shows you more data. It's also a bit more flexible, so you can tailor the output just how you like it.
Here's a command that shows you the name and permissions string:
Incompatible versions of stat are in use across systems. The above command works on Ubuntu, but on macOS, the equivalent is stat -f '%N %Sp' filename. Make sure to consult your stat's man page to check which options it supports.
You Can Modify Permissions With the chmod Command
chmod stands for "change mode," and it's your key to updating file permissions. Because of all the different settings, chmod can seem a bit daunting, but the good news is that it supports ...
Here's a simple example:
This command adds the read permission for all users to the file, myfile. In the argument "a+r," the "a" stands for "all users" and is a shortcut for "ugo" (user, group, other). You can use any combination of these three letters. Next, the "+" symbol stands for "add." Other options are "-" to remove a permission, or "=" to set the permission exactly. Finally, the "r" in this example stands for "read;" it could be any combination of "r," "w," for write, and "x," for execute.
You can even set multiple permissions at once:
This command lets the owner read and write a file, while everyone else can only read it. Nobody can execute it.
You should bear in mind that you can only use chmod to modify files you own (unless you have root privileges).
It's worth learning the basics of chmod and committing a few common cases to memory. But the command is powerful, and you can use chmod in many different ways .
You Can Use Them to Make Programs Runnable
We've mentioned the execute permission without really explaining it. This permission really does control whether you can run a file as a command . Typically, you'll use this permission with two types of files: binaries and shell scripts. Binaries are compiled programs that are run by the kernel, while scripts are run by an interpreter, such as a shell or a scripting language.
You should note that removing the execute bit does not prevent someone from running a program. While they will not be able to run it by directly typing the name of its file as a command, it will still be runnable by passing the file as input to its interpreter. For this reason, you should consider the execute bit as more of a safety net than a padlock. It's there to stop people accidentally running a program, not to make it impossible for them to do so.
Permissions Are a Safety Net, Not a Guarantee
Actually, the execute bit is not the only permission that isn't as firm a guarantee as you might expect. You should really think of permissions more as a set of guardrails than a rigorous safety harness.
Take the simple case of a read-only file: can you still delete it?
The rm command still lets you delete a file, even if you can't write to it! This feels counterintuitive, but it's really just a side effect of how permissions work. If you own a file, you can always use chmod to gain whatever access you want. So it makes sense that tools like rm give you the option of overriding file permissions in this special case.
Again, file permissions are to stop you from accidentally doing the wrong thing. They're there to prevent you from carelessly rm'ing an important document, not to ensure that document remains on your disk until the end of time.
They Have a Different Meaning for Directories
Since Linux treats directories as another type of file, they can also have permissions. However, due to their nature, permissions on directories have a slightly different meaning.
The read permission lets you read the contents of a directory, i.e., the list of files it contains. This means, for example, that you cannot run ls on a directory you cannot read:
The write permission lets you write the contents of a directory. For example, this controls whether you can create a new file inside a directory, or rename one inside it:
The execute permission is totally different; there really is no analogy that makes sense for running a directory! So, Linux overloads this permission for directories to mean something like "access the directory."
Most Graphical File Browsers Also Let You Manage Them
Ubuntu's Files app, like many GUI file browsers, lets you view permissions for a given file via its Properties context menu:
Permissions and Execute status are shown at the bottom of this dialog. You can click the Permissions row to view full permission details and update the read/write status for any set of users:
MacOS's Finder shows permissions in the Get Info dialog for any file:
The permissions show for the user, group, and other in rows from top to bottom. Note that Finder does not allow you to change the execute permission.
