The other chmod: with math

You will probably hate me for this, but I'm going to tell you about the binary number system now, and a little bit about the octal number system. There's a good reason though: The other way to assign permissions with chmod uses octal numbers, and it's the approach you'll come across most frequently in documentation.

Symbolic permission assignment is a newcomer on the scene, while using octal numbers has always worked with chmod. It's also a pretty readable system once you get used to it. It's painful to learn, but it's worth understanding how it works. So brace yourself, and read on.

Number systems

You might remember the binary system from math. They might also have called it "base 2". If you have not learned about it before, however, let's start by looking closely at the numbers you're used to working with.

Our "normal" number system is what's known as "base 10". Each digit of a number ranges from 0 to 9 — ten numbers in all. If a digit would be added to in a way that would make it be 10 or more, the extra numbers are added to the next higher digit in the numeral. That way the digits will always be less than 10 - the "base" value.

This also means that each digit in a number can be expressed in terms of powers of 10. And by "powers" I mean the successive results of multiplying by 10, except the first digit, which is the result of multiplying by 1.

The number "345", for example, breaks down like this:

3 x 10 x 10 = 300
4 x 10 = 40
5 x 1 = 5
300 + 40 + 5 = 345

Note that when you get down to the adding part, you're adding a three-digit number to a two-digit number to a one-digit number. When they're combined into one three-digit number you can see where each digit came from.

Now, when you move to a different "base", what you're basically changing is what number you multiply by to get the value of each digit in the number. So if you go from "base 10" to "base 8", the value of each digit in the number "345" changes. If you want to see what 345 in "base 8" looks like in our usual "base 10" system, you do some math that looks like this:

3 x 8 x 8 = 192
4 x 8 = 32
5 x 1 = 5
192 + 32 + 5 = 229

Weird, huh? What we see from that math is that "345 base 8" is equal to "229 base 10". That also means that "10" means something different in each number system. In base 10:

1 x 10 = 10
0 x 1 = 0
10 + 0 = 10

But in base 8:

1 x 8 = 8
0 x 1 = 0
8 + 0 = 8

And before you get too puzzled about "10=8", remember that we're using different "base" systems there. If we go back to the start of this discussion, we noted that in "base 10" no digit is higher than 9 - one less than 10. It's the same way in "base 8" - no digit goes up to 8, only to 7. If you get to 8, you insert a new digit in front of the number to represent the 8. Thus, "10 base 8" equals "8 base 10".

The binary number system

This leads us to the binary system, which is "base 2". No digit will be higher than 1 when we're working with binary (each digit can only be 0 or 1). That means "10 base 2" is, in base 10:

1 x 2 = 2
0 x 1 = 0
2 + 0 = 2

And "100 base 2" in base 10 is:

1 x 2 x 2 = 4
0 x 2 = 0
0 x 1 = 0
4 + 0 + 0 = 4

The digits proceed from there the same way - multiplying by 2 each time. So a list of the values of the digits in a base 2 number progress like:

1
2
4
8
16
32
...

Each value is a double of what came before.

Permissions as binary numbers

Now that you've got that jumble of information bouncing around in your head, let's look at the numerical equivalents of permissions, as far as chmod is concerned. In base 10, our usual number system, the values are:

r = 4
w = 2
x = 1

The reason those are the values assigned to each permission is because those numbers correspond to digits in the binary number system we were just discussing. In binary terms, then...

And now we reach the point where I explain why you really care about what a binary number is. Because if you look at the permissions on a file, you'll recall that they're expressed, in order, as "rwx". Or, if a permission is absent, a dash takes its place — like "r-x" if there's no write permission for that category.

If you think of each of those permissions as a binary digit, where "-" is 0 and anything else is 1, they could be written like this:

And in that way, with some funky math, we turn each of those permission trios into a single number! And now we can see why I used "base 8" as an example above: None of those numbers are above 7, so they could be expressed as single digits in base 8. Which leads us to...

Combined, and in octal

Another word for "base 8" is "octal", the same way another word for "base 2" is "binary" (and another word for "base 10" is "decimal"). The word "octal" shares the same root as "octopus", a creature named for its 8 legs, if you want an easier way to remember that. And you'll want to remember that, because I'll be talking about octal numbers now instead of the more awkward "base 8".

As you saw, a trio of permissions can be expressed as binary digits, and those digits represent a number that can be turned into a single octal digit. If that sentence made no sense, go back and try reading the previous sections again. Now that you've at least skimmed all that stuff about number systems, the earlier sections will hopefully be more comprehensible.

If it still doesn't make sense, post in the comments. You can help me figure out how to make it make sense.

Now, you may also recall that when we talk about a file's permissions, there are three categories: user, group, and other. And those categories are listed in order in a directory listing, just like each permission is listed in the same order each time.

So if you take the octal digit that expresses the permissions in each category, and you line them up in order, you get a three-digit octal number. And there you have it: How to set permissions with chmod in octal mode. Instead of "u=rwx,go=rx", you would have "755".

There are no relative assignments of permissions using octal. You either use a full three-digit octal number, or you don't use octal with chmod at all. That makes octal mode powerful (since you're assigning a lot of permissions with just three keystrokes), but also potentially lazy (since "755" sets everything to that permission, and doesn't distinguish between files and directories).

Octal examples

So now let's bring it all together to make that octal thing a little clearer. We'll look at some examples. First, a quick cheat sheet of commonly-used octal digits:

rwx = 7
rw- = 6
r-x = 5
r-- = 4

If you're not sure where those numbers came from, go back up and read the stuff about binary and octal again. Seriously, it's all worth it in the long run. I promise.

So. A common permission set for a directory is all access for the owner, and read and execute permissions for everyone else. In a long directory listing, a directory with those permissions might look like:

drwxr-xr-x 1 root root 622 Jan 11 2010 directory

In symbolic form, assigning these permissions would look like:

chmod u=rwx,go=rx directory

And in octal form, these permissions look like:

chmod 755 directory

If you're creating a file, you usually won't want to make it executable, so the default permissions for a regular file are usually read and write permissions for the owner, and just read permission for everyone else. In a directory listing that could look like:

-rw-r--r-- 1 root root 622 Jan 11 2010 file1

In symbolic form, assigning those permissions looks like:

chmod u=rw,go=r file1

And in octal form, it looks like:

chmod 644 file1

You can see why octal mode has stuck around as long as it has. Once you're used to it, it's easier to read a three-digit number than a bunch of letters and operators. It's just harder to understand the octal representation if you don't know what's going on behind the scenes.

Of course, if we want to combine the above permissions in a single statement (creating directories with executable permissions and files without), you can't do it with octal format. But you can with symbolic format thanks to that "X" permission we discussed earlier:

chmod u=rwX,go=rX directory file1

That's why I'd usually recommend using symbolic values with chmod if you're trying to change permissions for a bunch of files and directories all at once. Assigning "755" to everything in a directory could make a bunch of text files executable, which is messy and wrong (but easy). Assigning "u=rwX,go=rX" takes a little more thought to type, but applies the permissions more intelligently.

One more example before we leave this section: Assigning no permissions to a category. Let's say we want to set the permissions on a file so that it can be read and written to by its owner, and read by its group, but can't be accessed at all by everyone else. In a directory listing that might look like:

-rw-r----- 1 root root 622 Jan 11 2010 file1

In symbolic mode, assigning those permissions looks like:

chmod u=rw,g=r,o= file1

Notice how we didn't put anything after the last "=". That works. It just means that category gets nothing.

In octal mode, the chmod command would look like:

chmod 640 file1

Note the "0". The zero serves the same purpose as putting nothing after the equals sign in symbolic mode - that category gets no permissions.

One more look at symlinks

A brief and final note before you are declared fit to truly play with permissions: Symlinks act differently with chmod.

Remember, a symlink is a pointer to another file or directory. As a result, a symlink can have an owner, but it doesn't have any permissions of its own - all the permissions are set on the target file. So if you have "symlink1" pointing to "file1", then the command:

chmod 700 symlink1

would behave the same way as typing:

chmod 700 file1

This is logical, but it can also be dangerous when you have a bunch of symlinks in a directory and you recursively (with "-R") change the permissions of everything within. To be on the safe side, chmod ignores symlinks when changing permissions recursively. So if you run:

chmod -R 700 directory

Then you'll set the 700 permissions (all for user, none for group or other) on the directory plus all the regular files and directories inside "directory", but the permissions on the targets of all the symlinks inside "directory" will be left unchanged.

Summary

Wow, you actually made it through that? I'm impressed. I'm even more impressed if you understood even half of the stuff about chmod in one go — permissions are a pretty esoteric concept, considering how integral they are to working with Linux in general. So if you still feel a bit lost, that's actually pretty normal.

What I recommend now is to take the stuff we talked about so far and play with it. Get on a Linux system, make a new directory, cd into it, and then start making some more directories and files (you can use the "touch" command to create an empty file). Then go crazy with chmod. Add permissions, remove them, set them, and do an "ls -l" each time so you can see what happened. Practical experiments with chmod help a lot when trying to understand permissions.

Remember that you can test those permissions too. After you change permissions, see whether you can still create or delete files in a directory, or make changes to a file. You might also use "sudo" to run chown and chgrp to give files new owners and groups, then see what happens to your regular user's access to those files.

Once you understand permissions you'll be much better-equipped to both secure your system and to troubleshoot problems. A lot of errors can ultimately be traced back to permissions issues. A "403" error from a web site, for example, means "permission denied" - now that you understand permissions, you'll be able to hunt down the cause of that problem. Neat!

If you want to learn just about everything else about permissions and how they work in the file system, as well as some of the other file types you might see crop up in "ls -l" listings, continue to the next article. It talks about umasks and named pipes and stuff. They're the sorts of things it's good to know are there, even if you're not sure you'll ever actually use them.

-- Jered

Article Comments:

Victor commented Tue Sep 27 08:38:48 UTC 2011:

Hey, thanks Jered. This was a good explanation on CHMOD.

You can rest assured it is helping people.

Cheers!

Pablo commented Sat Feb 11 23:37:06 UTC 2012:

hey, thank you so much for this thorough, well-written article, it helped me a lot. I'll be sure to come back and read more!!