How Do Linux Permissions Work?

How Do Linux Permissions Work In Linux

You might remember when you first started working with Linux Permissions, thinking what are all these cryptic symbols next to files and folders in the terminal. Maybe you feel this way now if you’re just starting out with Linux. Let’s face it, when we see something like drwxr-xr-x 2 root root 4096 Feb 18 18:23 Code at the command line, it’s not exactly user friendly. Maybe you know that some of these symbols have to do with permissions, and if so you are right. So just how do permissions work in Linux anyway? Read on friend, since we are going to take a look at this very topic now.

Linux Permissions

Ubuntu has a nice overview of file permissions. This is a good resource to have.

Understanding Ownership In Linux

First up, we’re going to take a look at ownership. Now when we list out the contents of a directory, it might look something like this.

vagrant@homestead:~$ `ls -l`
total 8            
drwxr-xr-x 2 root root 4096 Feb 18 18:23 Code
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:53 ninja
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:28 secret
lrwxrwxrwx 1 vagrant vagrant 5 Feb 19 16:29 swift -> ninja
-rw-rw-r– 1 vagrant vagrant 62 Feb 19 16:13 ubuntu.txt

Say What? When we look at the output, at first it seems like just a random collection of characters with no meaning. Each character has meaning however, and each column has meaning. We placed this output into a table to drive home the idea of the seven different columns on output. Let’s take a look at column three and column four, and notice that they have names. These names are the owners of that particular entry. Column three is for User and column four is for Group.

chown and chgrp

There will be times we need to specify which user owns a resource and also which group it should be a part of. We do this with the chown and chgrp commands. We can test this out on the text file of ubuntu.txt listed above. As of now, the ubuntu.txt has both a user owner of vagrant, as well as belonging to the vagrant group. Do not be confused! We have a vagrant user, and a vagrant group. As a quick exercise, we can change the owner to root and the group membership to admin. Let’s try it out.

vagrant@homestead:~$ `sudo chown root ubuntu.txt`
vagrant@homestead:~$ `ls -l`
total 8            
drwxr-xr-x 2 root root 4096 Feb 18 18:23 Code
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:53 ninja
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:28 secret
lrwxrwxrwx 1 vagrant vagrant 5 Feb 19 16:29 swift -> ninja
-rw-rw-r– 1 root vagrant 62 Feb 19 16:13 ubuntu.txt
vagrant@homestead:~$ `sudo chgrp admin ubuntu.txt`
vagrant@homestead:~$ `ls -l`
total 8            
drwxr-xr-x 2 root root 4096 Feb 18 18:23 Code
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:53 ninja
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:28 secret
lrwxrwxrwx 1 vagrant vagrant 5 Feb 19 16:29 swift -> ninja
-rw-rw-r– 1 root admin 62 Feb 19 16:13 ubuntu.txt

Excellent. We can see that the ubuntu.txt file now has an owner of root and a group membership of admin. Great work.

Using The -R Flag With chown

The -R flag specifies to run a command recursively. This means it will iterate, or loop over, all of the files or folders available to the command. For example, we create a directory named directory. In that directory, we add four files named onefile, anotherfile, filethree, and filefour. Based on our current session, both the directory and all files are owned by vagrant and are also part of the vagrant group. Let’s just list that out to see what it looks like.

vagrant@homestead:~$ `ls -l directory`
total 0
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 16:52 anotherfile
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 16:52 filefour
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 16:52 filethree
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 16:52 onefile

Ok we can see our files as well as the associated user and group. Lets test out the -R flag with the chown command to change both the user and the group recursively.

vagrant@homestead:~$ `sudo chown -R root:admin directory`
vagrant@homestead:~$ `ls -l directory`
total 0
-rw-rw-r– 1 root admin 0 Feb 19 16:52 anotherfile
-rw-rw-r– 1 root admin 0 Feb 19 16:52 filefour
-rw-rw-r– 1 root admin 0 Feb 19 16:52 filethree
-rw-rw-r– 1 root admin 0 Feb 19 16:52 onefile

Just like we expected, both the user and the group have now been updated for the directory and all of it’s contents in one swoop. Of course this is a bit of a nonsensical example, but if you need to change a user or group on hundreds of files in a directory, you will come to love the recursive ability of the command line. Another thing you’ll notice is that its easy to use chown to not only change users, but groups. It does seem to make chgrp a bit redudant, but both exist, so feel free to use what you like. Let’s use chown to modify only the group membership, but not ownership.

vagrant@homestead:~$ `sudo chown :vagrant ubuntu.txt`
-rw-rw-r– 1 root vagrant 62 Feb 19 16:13 ubuntu.txt

Permissions On Files Folders and Links

Moving on from users and groups, we’ll now take a look at permissions on files, folders, and links. This is what you see in the very first column of output when you do a ls -l command for example. From all of the snippets we have seen above, we can see that this column consists of a string of 10 characters all in a row. At first, this information looks useless and confusing. In reality however, each individual character has special meaning.

The First Character

The first character of this group of 10 characters refers to what type of resource we are dealing with. Is it a file, a directory, or a link? Different characters of course have different meanings. - means it is simply a file. d means it is a directory, and l means it is a link.

The UGO Format

The second through tenth characters are what denote permissions on the resource. We have 9 total characters to work with, and this gets split into three groups of three. The first three are for the User. The second three are for Group, and the last three are for Other (sometimes also referred to as World). It looks like this for a directory which has read, write, and execute permissions, for User, Group, and Other.


When a particular permission is not enabled, it is represented simply by the - character. So lets take away write permissions from the Group, as well as Other. What would that look like?


Representing Permissions As Octal Numbers

The string of 9 characters used to show permissions on a resource can also be represented as an octal number. This means instead of something like rwxrwxrwx, you could simply refer to this as 777. How does this work? Lets see.

Octal Assignment

  • r = 4

  • w = 2

  • x = 1

type user group other
d rwx r-x r-x
d 7 5 5
rw- rw- r- –
6 6 4

The table above is easy to figure out, and this is how you can figure out exactly what permissions a resource has by simply looking at the three digit octal value. We know that read has a value of 4, write has a value of 2, and execute has a value of 1. This ingenious method allows the full range of permissions to be assigned using only 3 digit spaces. Here is the full chart of octal to permission representation.

octal permission
0 - - -
1 - - x
2 - w -
3 - w x
4 r - -
5 r - x
6 r w -
7 r w x

So How Do You Assign Permissions?

That is indeed a great question, and there are a couple of ways to do it via the chmod command. In order to use chmod on a resource, you must be either the owner of that resource or the superuser. The first and most common way is probably by using octal notation. Here is an example of testing the ownership theory along with setting permissions via octal notation.

vagrant@homestead:~$ `chmod 777 ubuntu.txt`
chmod: changing permissions of ‘ubuntu.txt’: Operation not permitted
vagrant@homestead:~$ `sudo chmod 777 ubuntu.txt`
vagrant@homestead:~$ `ls -l`
-rwxrwxrwx 1 root vagrant 62 Feb 19 15:38 ubuntu.txt

Excellent! Here we see that when we first tried to change the permissions, we were given an error message that we were not allowed to do so. This is because we are operating as the vagrant user, however root is the account that owns the file. Note that when we prefix the sudo command, it works successfully. It’s worth mentioning what sudo actually is, since we’ve used it a few times so far and have not provided the meaning of it. sudo allows a user to gain elevated rights for specific operations, without needing to be the root or superuser. Most system administrators will advise you not to operate as the root user. It’s far too dangerous. If you have one slip up, or typo, you could potentially cause major damage to the system and render it unusable. By working as a user account, and only invoking sudo when needed, you are protecting yourself from potential pitfalls.

The second way to change permissions is with the symbolic representation. This amounts to using the letters u, g, and o, in combination with minus and plus signs along with the permissions in question such as r, w, and x. It’s a little ambiguous, so let’s see an example or two.

vagrant@homestead:~$ `chmod ugo-x ubuntu.txt`
vagrant@homestead:~$ `ls -l`
-rw-rw-rw- 1 vagrant vagrant 62 Feb 19 15:38 ubuntu.txt

Notice how we specify the User, Group, and Other, with ugo, then we are saying remove executable permissions for all three of these via -x. Listing out the contents with ls -l confirms the result. Here are a few ways to use symbolic notation.

symbolic notation resulting effect
u+w add write permission for the owner
u-x take away execute permission on the owner
+r add read permission for user, group, and other
o-rw remove read and write from other
uo-rwx remove read, write, and execute, from both user and other
ugo+rwx allow full access equivilent to 777 for user group and other

Note that other is also sometimes referred to world, or everyone else.

Executable Permissions Work Differently For Files vs Folders vs Links

In Linux, you’ll often see that the executable permission is set on folders. This is because, without the executable permission, you are unable to cd into a directory. Further, you’ll need the read permission set in order to do an ls to list the contents of the directory. Files on the other hand, do not typically have execute permissions by default. This is for security concerns, since you would not want a file with any malicious code or software to be freely executable by the system. Finally we have permissions on Links. We haven’t covered links in Linux yet, but you may already know what they are, and if you don’t, you can think of them like shortcuts. Links typically have all permissions across all groups. This is because the link simply uses the permissions of the resource it points to. Let’s review it on our system.

vagrant@homestead:~$ `file swift`
swift: symbolic link to ‘ninja’
vagrant@homestead:~$ `ls -l`
-rw-rw-r– 1 vagrant vagrant 0 Feb 19 15:36 ninja
lrwxrwxrwx 1 vagrant vagrant 5 Feb 19 15:38 swift -> ninja

By this example we can see that swift is a symbolic link that points to a ninja. Even though swift appears to have rwxrwxrwx permissions, it actually has -rw-rw-r-- permissions because that is what the ninja has.

How Are Permissions Assigned When You Create Them?

With all of this talk about what permissions are, and how to configure them, it does bring us to the question of how files and folders get their permissions in the first place. Hmm, good question, right? Well, let’s go ahead and create a new file, and see what the permissions it has are.

vagrant@homestead:~/directory$ `touch newfile`
vagrant@homestead:~/directory$ `ls -l`
total 0
-rw-rw-r– 1 vagrant vagrant 0 Feb 20 17:43 newfile

So this is interesting. It looks like when a file is created, it has -rw-rw-r-- permissions by default. Ok great. Well, where does that come from?

Behold The UMASK

The umask is used in combination with the octal permission assignment to determine how to assign permissions to files and folders on creation. There are a few places to tinker with umask in Linux based on the distribution in use, and the user you are logged in as. The takeaway however, is that the umask is most commonly set to 022, giving us folders of 755, and files of 644 upon creation. How does this work? It’s easy. You start with the 777 permission, then subtract the umask. So 777 – 022 = 755. Now how come files come out as 644? This is because Linux simply strips the executable bit immediately upon creation to remove any security risk for files.

Just when you thought there was nothing else to learn about permissions in Linux, along comes the setuid bit, the setgid bit, and the sticky bit. Say What? Let’s examine.


The setuid bit is used on executable files. It is also sometimes known as set user id. If this bit is set, the file will run as the owner of the file. What does this mean? Well, suppose there is a file on the system that is owned by root. Along you come as a user account, and you run that executable file. If the SUID is set, that file will run as root, even though you might be logged in as Emmet. You typically don’t mess with the SUID, and it is dangerous if configured improperly, but we include it for completeness.


GUID is used on both executables and folders. Group user id works similar to suid in that it alters permissions whether it is set or not. If it is set on an executable file, then the file runs with the permissions of whatever group owns the file. When applied to folders, the result is that any files or folders created within the parent folder will be owned by the group. In other words, all new files or folders will inherit group ownership from whatever group ownership the parent folder has.

Sticky Bit

Finally, we have the sticky bit. It’s not actually used all that much these days on files, but there are some use cases for it on folders. The most common place we see it in use is on the /tmp directory. What it does is to say that only the owner of a file or folder, can delete that file or folder. This makes perfect sense for the /tmp directory because there will be multiple users and groups writing to and reading from the /tmp directory. Well guess what. You don’t want other users to come along and delete anything that you need access to. Now when we say users, these often refer to the user processes used by applications, not actual human users.

Representing SUID GUID and Sticky Bit

You are surely familiar with the format of 777, or 664, to represent permissions in Linux. Well what about the times you see 4 digits like 4755, or 2775? The answer is that the first digit is an octal representation of the SUID, GUID, and Sticky Bit. We already had a look at how to calculate permissions using octal for the User, Group, and Other. Well, it works the same way for SUID, GUID, and Sticky Bit. Let’s see how. Recall our list:

  • r = 4

  • w = 2

  • x = 1

Now simply update it to see how these values are set with regard to SUID, GUID, and Sticky Bit.

  • SUID = 4

  • GUID = 2

  • Sticky Bit = 1

Now you can simply add the numbers up to understand what is set. For example 1777 has the sticky bit set, 2777 has the guid set, 4777 has the suid set, and 5777 has both the suid and sticky bit set.

An Example SUID Use Case

The built in ping program is a good example of the SUID bit being set. Let’s see it in action.

vagrant@homestead:~/directory$ `ll /bin/ping`
-rwsr-xr-x 1 root root 44168 May 7 2014 /bin/ping*

Do you notice anything funky there? That’s right, have a look at -rwsr-xr-x and notice the letter s in there. What that means is, when I run the ping program from the vagrant account, ping is going to run as root. See how that works?

An Example GUID Use Case

Suppose we have a script on the machine, and we want that script to run with group permissions no matter who triggers it. Let’s see how to do that.

vagrant@homestead:~/directory$ `sudo chmod g+s pretendscript`
vagrant@homestead:~/directory$ `ll`
-rwxrwsr-x 1 vagrant admin 30 Feb 20 18:35 pretendscript*

In this example we can see that the GUID is set by the s in the permissions -rwxrw<strong>s</strong>r-x. The letter s is still used, however it is placed in the location of the executable bit for the group permissions like you see here. In this case, this file will always run with the permissions of the admin group.

Linux Permissions Summary

Permissions are a pretty vast topic in Linux. We had quite an epic investigation of permissions in this episode where we learn how permissions work in Linux. We covered a lot of ground with respect to users, groups, permissions, octal notation, symbolic notation, the UGO format, umask, suid, guid, sticky bit, and more. Having a solid grasp of how these concepts work in Linux is vital, since they affect all aspects of working with various programs and information in Linux.