File and Directory Permissions

A strong understanding of file and directory permissions is vital for a strong understanding of the Linux operating system as a whole. In this article, we will begin by offering a general overview as well as a couple of examples. The article will finish with some reference tables to allow you to get a complete picture of the power (and the danger) of access controls.

Let's start by attempting to understand the permissions of a standard text file. We can view these permissions by running "ls -l":

demo:~$ ls -l
-rw-r--r-- 1 demo demogroup 1648 2009-07-15 09:58 file.txt

The first section, "-rw-r--r--", is exactly what we're looking for here. (The owner and group are also important, but we'll get to that later.) Without getting into too many details too early, this tells us three things:

  • The file's owner (demo) may read and write the file.
  • Members of the file's group (demogroup) may read, but not write to, the file.
  • Other users, a.k.a. the world, may also read, but not write to, the file.

What, exactly, does it mean when a file has "read" or "write" permissions? Perhaps this table can explain better than I can...

Access File Directory
Read File contents may be read Directory contents may be listed
Write File may be written to Files in the directory may be created/moved/deleted
Execute File may be executed Directory may be made the working directory ("cd'd" to)

Now then, let's say that we want our friends in the demogroup to also be able to modify the file. We can fix this with the following command:

demo:~$ chmod g+w file.txt
demo:~$ ls -l
-rw-rw-r-- 1 demo demogroup 1648 2009-07-15 09:58 file.txt

Piece of cake! But what if this creatively-named file contains deep, dark secrets? What if we don't want to share its contents with anyone outside of the demogroup clique?

demo:~$ chmod o-r file.txt
demo:~$ ls -l
-rw-rw---- 1 demo demogroup 1648 2009-07-15 09:58 file.txt

Presto. You can learn more about the syntax of the "chmod" command by running:

man chmod

But what about those letters and dashes? What, exactly, did they mean? Permissions may be specified in two representations -- textual and numerical. "ls -l" displays them in letters, but the "chmod" command will accept either form. We will now fully explain the letters and dashes.

This table uses the following notation:

drwxrwxrwx <-- Values
9876543210 <-- Position
Position Effect Values
9 File Type "d" symbolizes directory, "l" symbolizes link, "-" is a normal file. You may also see letters "b", "c", "p", and "s".
8 User Read "r" or "-"
7 User Write "w" or "-"
6 User Execute "x" symbolizes non-SUID execute. "s" symbolizes SUID execute, while "S" symbolizes SUID without execute.
5 Group Read "r" or "-"
4 Group Write "w" or "-"
3 Group Execute "x" symbolizes non-SGID execute. "s" symbolizes SGID execute, while "S" symbolizes SGID without execute.
2 Others Read "r" or "-"
1 Others Write "w" or "-"
0 Others Execute "x" symbolizes non-Sticky execute. "t" symbolizes Sticky execute, while "T" symbolizes Sticky bit without execute.

Of course, this brings us to another question... What's that about SUID, SGID, and the sticky bit (oh my!)? Once again, a table seems appropriate...

Access File Directory
SUID (setuid) File executes with rights of its owner (not the user who executed it) Ignored
SGID (setgid) File executes with rights of its group (not the user who executed it) Files created within directory inherit the directory's group memberships (rather than the creator's group memberships)
Sticky Bit Ignored Files created within directory may only be moved or deleted by their owner (or directory's owner)

This probably isn't intuitive, so we'll go over it in a bit more detail. First, the sticky bit. One place the sticky bit is commonly used on Unix-like systems is the /tmp directory. This directory needs to be world-writable, but you don't want anyone going around and deleting everyone else's files. The sticky bit offers exactly this protection.

In practice, regular users will rarely set the SUID or SGID bits themselves. These are generally only found on specific system binaries and daemons. For example, the "passwd" program (owned by root) must have SUID set to allow users to change their own passwords.

Having said that, here is a file you certainly never want to see on your Cloud Server:

-rwsr-xr-x 1 root root      2928 2009-07-15 10:03 evil.bin

Can you understand why?

This article will conclude with an overview of the octal permissions representation. This table will use the following notation:

4755 <-- Octal Value
3210 <-- Octal Bit
Octal Bit Effect
3 SUID, SGID, Sticky Bit
2 User (Owner)
1 Group
0 Others (World)


Octal Value Binary Value Octal bit 3 Octal bits 0-2
0 000 No Effect Deny All
1 001 Sticky Only Execute Only
2 010 SGID Only Write Only
3 011 SGID/Sticky Write/Execute
4 100 SUID Only Read Only
5 101 SUID/Sticky Read/Execute
6 110 SUID/SGID Read/Write
7 111 SUID/SGID/Sticky Read/Write/Execute

Was this content helpful?

© 2015 Rackspace US, Inc.


See license specifics and DISCLAIMER