Linux file permissions are mysterious, and when faced with permissions errors, most researchers respond either by using
sudo or by changing the permissions so that everyone can do everything to the files. The first is the equivalent of finding a locked door and bashing it in, and the second is the equivalent of leaving all the doors and windows open, with some snacks on the kitchen table for the intruders.
Here we demystify Linux permissions for you.
How to interpret all the bits
First we need to understand where to see file permissions and the individuals and groups that they refer to. If you type the command
ls -l as shown below, you will see a directory listing with some extra information about each of the items. I've created a few small files and a directory here.
$ ls -l
-rw-rw-r-- 1 tara friends 22 Aug 12 14:14 bar
-rw-r--r-- 1 tara friends 18 Aug 12 14:14 baz
-rwxrwxr-- 1 tara tara 10 Aug 12 14:14 foo
drwxrwxr-x 2 tara tara 4096 Aug 12 14:26 subdir
You will notice that for each file or directory there is a 10 character block at the start of the line. The first character indicates the file type. Most commonly it is a regular file (
- ), as for the first three files (
foo), or a directory (
d ) as for the directory
The next 9 characters up to the space is the permission block. This is followed by the number of links to the file (don't worry about that for now), and then the owner of the file
tara and the group of the file (here,
tara). After that is the size of the file in bytes, the date/time it was last modified (if it is a file) and the date/time it was created (if it is a directory) and finally, its name.
The concepts of owner and group are critical to understanding permissions. The owner is the person who owns the file. The group is like a group of friends who can be granted special privileges to do things with the file. Everyone else who is not in the owner or the group is "other".
In the permissions block above, the first three characters (rw-) refer to the ability of the owner to read (r), write (w) or execute the file (x). You allow a file to be executable if it is a script (e.g. Python or bash) so that you can run it from the command line like any other program. This character will be a - if the permission is not granted. Note above that
foo is executable by the owner. Each of these characters is actually an on/off switch which is a "bit" (a 1 for granted or a 0 for denied) in the underlying representation, so you will often see a numerical representation of these permissions bits in tutorials you read on the web (more on this later).
The second three characters (rw-) refer to the ability of the group to read, write or execute the file. For the file
bar, all members of the group "friends" can read and write the file. For the file
baz, members of the group "friends" can only read the file. The group for the file
foo is tara, which is a group consisting of only me. Therefore, although I am setting group permissions on this file to be read, write and execute, I am not actually giving anyone else any access.
The final three characters are permissions for "other" - anyone who is not an owner or in the group associated with the file. This is everyone else who has an account on the computer. You should be careful with these permissions, because granting read permissions to everyone may reveal sensitive data, and granting write permissions to everyone will allow anyone to modify your files.
Finally, note that the directory
subdir is executable. That probably seems weird at first - but it is because read, write and execute have slightly different interpretations for directories. For directories:
- read allows a user to list the files within the directory
- write allows a user to create, rename, or delete files within the directory
- execute allows a user to
cdinto the directory, and access its contents
Learning about myself
To find out your username (which you may already know):
To find out what groups you belong to (which may surprise you):
By default, the first group is the list is the one that will be assigned to files you create.
To find out who is in a group, you can use the command
sudo is the group you are trying to learn about, and the users will be listed after the last colon.
getent group sudo
If you are on Ubuntu, you can instead easily install the command
members, which formats its output nicely:
sudo apt-get install members
Changing file owners and groups
To change who can access a file according to the permissions, first think about the owner and group of the file. If you are the only human using the computer (as you might be when using a RONIN machine) and you are having difficulty reading/writing a file or changing into a directory, it may be that you are not the owner of the file. This is common when you do things as
root that write to your home directory or set permissions incorrectly in system folders.
To change the owner of a file or directory from root to ubuntu (assuming your username returned by
whoami is ubuntu) we use the
chown command, which stands for "change owner":
#change owner of a single file called "myfile" to "ubuntu"
sudo chown myfile ubuntu
#change owner of a whole directory called "mydir" (including all files and directories within it) to "ubuntu"
sudo chown -R mydir ubuntu
On RONIN you probably won't encounter groups as much, as you and your superuser self (root) are the two main users of each machine. However, to change the group of a file we use the
chgrp command, which stands for "change group":
#change group of a single file called "myfile" to "friends"
sudo chgrp myfile friends
#change group of a whole directory called "mydir" (including all files and directories within it) to "friends"
sudo chgrp -R mydir friends
Once you have correctly configured the user and group of the files whose permissions you are trying to correct, you need to change the permissions. This confusing only because there are multiple ways to issue the change permission command.
The first way is to simply specify exactly what the permissions that should be granted are for owner (u), group (g) and other (o) using the
chmod command as below. The letters u, g, and o stand for "user" (which is the file owner), "group", and "other". The equals sign ("=") means "set the permissions exactly like this," and the letters "r", "w", and "x" stand for "read", "write", and "execute", respectively. The commas separate the different classes of permissions. There should be no spaces between them!
chmod u=rwx,g=rx,o=r myfile
There is a shorthand for this exact specification of permissions. Note that for each entity (user, group and other) there are exactly 8 combinations of permissions. These each can be represented by a sequence of 0s and 1s (for permission denied or granted respectively), and these sequences can be represented as a single digit in octal representation. We are basically just counting up permissions from 0 to 7 for each entity.
Thus, instead of specifying the characters for the permissions as above, you can simply use the octal representation:
#the following two commands are equivalent
chmod u=rwx,g=rx,o=r myfile
chmod 754 myfile
Now AWS instructions to change permissions on your ssh key with "chmod 400 mykey.pem" make sense. By the table above, this sets permissions so that only you can read it.
When you create a new file, what permissions does it have? It's not random... it is determined by the user's file creation mask, or
umask. To see what your default umask is:
On my system this returns
0002. Focus only on the last three digits (
002 ) , which are relevant to the permissions we are discussing. The umask is the complement of the permissions you give to a file using
chmod. By this logic, a umask of
022 means that user can have all permissions, and group and other can read and execute the file (important if it is a directory), but not write to it. This makes good sense as a default; to open things up to a group I have to explicitly change the permissions.
We've only touched on the basics here. The best way to learn this stuff is to practice changing permissions, see what happens, and see if it is what you expected. On RONIN, because typically each machine has only one human user, most permissions issues arise because the
root user owns files and has prevented access. However, permissions are also very important to protect data from accidental deletion or modification. And with a knowledge of Linux permissions you can astound and impress your colleagues!