Garbage Collector

The little space of a writer, tinkerer, and a coffee addict

Linux Explained part 4 : The files permissions

Linux Explained part 4 : The files permissions
Tux, the Linux mascot

In this fourth entry of our Linux Explained series, following the filesystems definition, we will now see how Linux manages the access to the files and folders.

The file permissions

Now we have seen how do Linux organizes its filesystem, let’s see how it manages the permissions of the files and folders.

It won’t be a surprise, Linux’s file permissions are also inherited from Unix. The file permissions are one of the core features of Linux’s security model : determine who can access to what and what they can do on it. Of course, and the security parenthesis later will confirm that, the file permissions are just a component among several other ways to secure a Linux installation.

How to see the file permissions

Let’s list my /etc directory content. This time, I use the ls -l command that will display the files metadata.

drwxr-xr-x.  3 root        root         4096 Mar 10  2022 abrt
-rw-r--r--.  1 root        root           16 Feb  4  2020 adjtime

In this result, I have to types of files : a directory, and a file. How can I see the difference ? Here is how to read this output.

For the adjtime file, we have the following elements that interest us in this particular case :

For the abrt file, you may had noticed a difference with the first character : d. That means it’s a directory. You may also noticed that the permissions are different.


Remember : for Unix, everything's a file ! No matter if its a directory or a text file or a hard drive or an executable program.

How to read the file permissions

In our previous example, we had two different set of permissions for a file : rwxr-xr-x and rw-r--r--. These strings are actually composed of three blocks :

These three blocks stand for, in this order :

Now, we have letters, what do they mean ?

If the letter is present, the permission is granted for the related set of permissions (owner/group/others). If not, the permission is replaced by the - symbol.

When a user requests an access to a file, the system will check in the following order if the permissions allow it :

  1. Check if the user is the owner of the file. If so, no other checks will be made.
  2. If you’re not the owner of the file, the system will check if you’re a member of the group owning the file. If that’s the case, you will have access to it according to the group’s permissions
  3. If you’re neither the owner or belonging to the group, the system will use the others permissions.

The three permissions sets are mutually exclusive.

The permissions grant a specific access the file :

Let’s show an example, I’ve wrote a file name file.

$ ls -l file
-rw-r--r--. 1 seb  seb     6 Feb  8 22:41 file
# my user and group are owner, and the others can read.
$ echo something >> file
$ ls -l file
-rw-r--r--. 1 seb  seb    16 Feb  8 22:42 file
# The content size changed.
# I've changed the owner, now it's root.
$ ls -l file
-rw-r--r--. 1 root root   16 Feb  8 22:42 file
$ echo somethingelse >> file
zsh: permission denied: file
# I can't write anymore in this file.
$ cat file
# but I can still read it
# I remove the Read access to Others
$ ls -l file
-rw-r-----. 1 root root   16 Feb  8 22:42 file
# Let's try to read it
$ cat file
cat: file: Permission denied
# :(

A security parenthesis

A little note about Linux’s security. A common mistake is usually to believe that removing the Execute attribute to a file will protect the system from uncontrolled script executions. But like we said, using the interpreter executable command will make this idea irrelevant for an interpreted programmation language such as the shell, Python, Perl or Java. If you want to prevent the execution of commands and script from a specific filesystem (typically : the home users directory), you need to apply a specific flag to the mountpoint : noexec. Of course, it’s just one possibility among a lot of other one in order to secure a Linux installation.

Another common mistake is to believe that thanks to its file permissions system, Linux is “more secure” than Windows, but that’s terribly wrong. Linux is today as much targeted by malwares as Windows, but the attack patterns are different. So this reminder seems important to me :


A Linux Distribution is not more or less secured by design than any other operating system, and especially not out of box. Securing and hardening a Linux installation is a specific work requiring advanced competences in matter of system administration and IT security. And more important : Linux is not foolproof !

Additionally, I’ll complete with another very despicable practice I can still see today… Applying the full permissions access to a file. If you read any tutorial or advice telling you “use chmod 777 file”, don’t do that unless you fully understand, and have challenged, this requirement. In other cases, that’s a terrible practice. It’s basically giving an open bar access to the content without any control over it.

The octal values for permissions

The example about the bad practice is a nice transition to a second way to read (and specify) your filesystem’s permissions : the octal value. Instead of using the letters notation (r, w, x), you use numbers : respectively 4, 2, 1.

In the bad example I’ve exposed just above, I’ve used the command chmod. This command changes the permissions of a file, and in this case, I’ve used the octal notation. 777 = rwxrwxrwx here. The three numbers represent the Owner, Group, and Others just like the three rwx groups.

If we recall our first examples with the adjtime file and abrt folder, here is the correspondance of their permissions :

Each permission set is the addition of the three octal values :

So, if I use a concrete application of the command chmod :

And that’s why I prefer the octal notation, it’s easier to apply and to learn. Once applied, we have the following result :

$ ls file
-rwxr-----. 1 seb  seb    16 Feb  8 22:42 file
# Want to display the octal notation ? use the 'stat' command
# And check "Access"
$ stat file
  File: file
  Size: 16        	Blocks: 8          IO Block: 4096   regular file
Device: 0,33	Inode: 2013        Links: 1
Access: (0740/-rwxr-----)  Uid: ( 1000/     seb)   Gid: ( 1000/     seb)

# I'm curious, what is the Access on a folder ?
$ stat snap-private-tmp
  File: snap-private-tmp
  Size: 40        	Blocks: 0          IO Block: 4096   directory
Device: 0,33	Inode: 2           Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)

If you read these two stat output you may want to recall the d letter before the permission suggesting a folder. For snap-private-tmp yes, we have it : drwx------. This folder has very restrictive accesses : only root can read, write and access to its content, nobody else.

But if you read carefully both of these outputs you may possibly ask :

Hey, why is there a 0 before 740 and 700 ? Is that the octal value for the directories ?

Nope, that’s something else :

The special file permissions

Actually, the octal notation is on 4 numbers, not 3. The first digit is here to apply the special file permission. These special permissions grant additional privileges to the files and directories :

A very good example of the SUID usage is the sudo command. sudo is an administrative tool that permit an authorized user to impersonate another identity on the system. To be able to work, the command uses the SUID and is owned by root. Since root can switch to any other user with no password prompt, this command will temporary grants a root permission to the user invoking it.

$ stat /usr/bin/sudo                                                                                           
  File: /usr/bin/sudo
  Size: 202328    	Blocks: 400        IO Block: 4096   regular file
Device: 253,0	Inode: 2497570     Links: 1
Access: (4111/---s--x--x)  Uid: (    0/    root)   Gid: (    0/    root)

sudo has very interesting permissions : 411

But these permissions grant the possibility to execute the command for anybody. And because of the presence of the SUID flag (4), the command will always be executed with root’s permissions.

Example :

# Using the whoami command, that displays
# the current user's name
$ whoami
# by default sudo switches to root
$ sudo whoami
# but you can specify a username
$ sudo -u apache whoami
# that's the magic of the SUID

Mmmh how can the file permissions secure Linux if a command can allow anybody to become super admin ?!

Good question : sudo is not a dumb command. It relies on a list of allowed users with the commands they can perform as another one, the sudoers. So if the current user is not in the sudoers, sudo will reject the input and report the incident.

Now let’s make an example for the SGID, which ensure the files created in a directory will always have the directory’s permissions whoever is writing them.

# I have created two directories
# One "sgid" owned by me and the "root" group, with the SGID
# One "nosgid" owned by me and the "root" group, with no SGID
# The Others has no permissions
$ ls -l
drwxrws---. 2 seb  root   60 Feb  9 23:01  sgid
drwxrwx---. 2 seb  root   40 Feb  9 23:01  nosgid
# I create a file in the nosgid folder using the "touch" command
$ touch nosgid/test
$ ls -l nosgid/test
-rw-r--r--. 1 seb seb 0 Feb  9 23:04 nosgid/test
# Me and my group are owner
# Now let's try in the sgid folder
$ touch sgid/test
$ ls -l sgid/test
-rw-r--r--. 1 seb root 0 Feb  9 23:06 sgid/test
# The group owning the file is root's, not mine

The special permissions have both the letter and octal notation, just like the regular one.

We will explain Sticky in the next step.

The permissions I’ve used in the example above have been set like this :

Another special permission, the Sticky Bit

The Sticky bit is set at the Others level and is different than the two previous special ones because it doesn’t affect the files themselves. Set at the directory level, the sticky bit restricts the file deletion inside this directory. Only the Owner of a file is able to delete it inside this directory. And of course, root is also capable of it because it can do anything.

Basically, root don’t care about the file permissions.

The sticky bit is noted with the T letter at the Others level. It’s octal value is 1.

Example in application :

# I've created a "sticky" folder with permissions 1770
# And a "nosticky" folder with permissions 0770
# apache is the group owner of the folder
$ ls -l
drwxrwx--T. 2 seb  apache    40 Feb  9 23:19  sticky
drwxrwx---. 2 seb  apache   60 Feb  9 23:28  nosticky
# I've been able to create a file inside
# apache too.
$ ls -l *sticky
total 0
-rw-r--r--. 1 apache apache 0 Feb  9 23:30 file-apache
-rw-r--r--. 1 seb    seb    0 Feb  9 23:30 file-seb

total 0
-rw-r--r--. 1 apache apache 0 Feb  9 23:30 file-apache
-rw-r--r--. 1 seb    seb    0 Feb  9 23:30 file-seb

# apache as full access to the directory thanks to the group
# this user can delete a file owned by somebody else
$ sudo -u apache rm nosticky/file-seb 
rm: remove write-protected regular empty file 'nosticky/file-seb'? y
# but in the folder protected by the sticky bit,
# despite having a full access, apache is denied from 
# removing a file owned by seb
$ sudo -u apache rm sticky/file-seb
rm: remove write-protected regular empty file 'sticky/file-seb'? y
rm: cannot remove 'sticky/file-seb': Operation not permitted

So far…

Our Linux exploration journey has been quite rich. Some history, the basics about how the system is starting, the relation between the core components, and now how a storage is exploited, organized, and how do we ensure the expected people has access to their expected resources.

The next part of our explanations we be about the users management. We talked a lot about the users and groups in this article, so it seems to be the next logical step.

πŸ“‘ Table of Contents

πŸ“š Read my latest book

Follow me on Mastodon

🏷️ All Tags πŸ“„ All Posts πŸ—Ί Sitemap RSS Feed