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...

ReadFile contents may be readDirectory contents may be listed
WriteFile may be written toFiles in the directory may be created/moved/deleted
ExecuteFile may be executedDirectory 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:

9File Type"d" symbolizes directory, "l" symbolizes link, "-" is a normal file. You may also see letters "b", "c", "p", and "s".
8User Read"r" or "-"
7User Write"w" or "-"
6User Execute"x" symbolizes non-SUID execute. "s" symbolizes SUID execute, while "S" symbolizes SUID without execute.
5Group Read"r" or "-"
4Group Write"w" or "-"
3Group Execute"x" symbolizes non-SGID execute. "s" symbolizes SGID execute, while "S" symbolizes SGID without execute.
2Others Read"r" or "-"
1Others Write"w" or "-"
0Others 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...

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 BitIgnoredFiles 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 BitEffect
3SUID, SGID, Sticky Bit
2User (Owner)
0Others (World)


Octal ValueBinary ValueOctal bit 3Octal bits 0-2
0000No EffectDeny All
1001Sticky OnlyExecute Only
2010SGID OnlyWrite Only
4100SUID OnlyRead Only

Was this content helpful?

© 2015 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

See license specifics and DISCLAIMER