Brilliantly simple: The Linux File System

Note: This is a re-publish from the original post at Hashnode.

The simple and effective design of Unix/Linux has been inspiring for any one who studies them. There are some gems in Linux filesystem that has awed me and here's me sharing them.

File Permissions

Any file has nine bits of permissions, three each for:

Owner of the file - usually the user that created the file.
User group that owns the file - usually the group the user belongs to.
All others - rest of the world.

And the three bits are rwx for read, write and execute.

-rw-rw-r-- 1 user1 user1 0 Jun 24 10:13 temp

The first bit - in the listing above is for type of file, - just means a normal file other values can be d, c , b etc.

So the user1 and group has read and write permission on file temp an all others have read-only permission. The default permission for any file is decided by setting of umask - We'll not go into details at this point.

What exactly these rwx means?

r - permission to read file contents.
w - permission to change file contents.
x - permission to execute the file as a program.

For example, permission on cat program:

-rwxr-xr-x 1 root root 35288 Feb  8 09:16 /usr/bin/cat

/usr/bin/cat is owned by root user and group but only root user can overwrite it. Users belonging to root group and others can execute the program.

You'll say rwx is pretty much what it says, quite simply, yes. But there are subtle differences of same permission bits when it comes to other types of files.

SETUID Bit on Files

Users on Linux also need to perform certain actions which needs super user permissions. For example, changing passwords or switching user. There are specific commands for these, here is a couple of permissions of these commands/programs:

# ls -l /usr/bin/passwd /usr/bin/su /usr/bin/sudo
-rwsr-xr-x 1 root root 232416 Apr  3  2023 /usr/bin/sudo
-rwsr-xr-x 1 root root  59976 Feb  6 18:24 /usr/bin/passwd
-rwsr-xr-x 1 root root  55680 Apr  9 21:02 /usr/bin/su
#

Permissions set on these are rws for owner (which is root). This means that whoever runs these programs, it will be executed as root user and hence will have super user privileges.

It is intriguing, what if any of these special programs have write permissions for others? That will allow any user to overwrite these files/programs with malicious code and whenever that program is executed, it will have super user privileges.

You can find all program files with SETUID bit using find /usr/bin -perm /u+s

Directory Permissions

A Directory is just a special case of file. Take a look at this:

rajesh .../blog $ ls -ld /usr/bin/
drwxr-xr-x 2 root root 86016 Jun 24 09:12 /usr/bin/
rajesh .../blog $

So /usr/bin directory is owned by root user. Note the first bit changed to d since this is a directory. Now lets look at what these rest of nine bits of permission means.

r - means directory is readable - list contents of directory using ls or other commands or system/function calls.
w - write permission means to be able to create/delete/rename files. Note that creation/deletion/renaming of file DOES NOT depend on file permissions but on directory permissions.
x - execute a directory? No, a directory surely cannot be executed as a program :) rather it means to be able to list the file if you know the complete path name, even if you do not have read permission on that directory. Following example should make it clear:

```bash
# mkdir /tmp/test
# ls -ld /tmp/test
drwxr-xr-x 2 root root 4096 Jun 24 11:34 /tmp/test
# chmod 751 /tmp/test/
# ls -ld /tmp/test
drwxr-x--x 2 root root 4096 Jun 24 11:34 /tmp/test
# 
# touch /tmp/test/temp
```

Set of commands above makes a directory /tmp/test and changes the directory permission to drwxr-x--x - note only execute permission is given to others, no read permission. Then as normal user:

rajesh .../blog $ ls -ltr /tmp/test/
ls: cannot open directory '/tmp/test/': Permission denied
rajesh .../blog $ ls -ltr /tmp/test/temp
-rw-r--r-- 1 root root 0 Jun 24 11:35 /tmp/test/temp
rajesh .../blog $

On close inspection, you'll find that listing of directory contents is denied but you could still list the file since you used the complete path name. That happened because of x permission on directory for others.

Sticky Bit Directory Permissions

There is a special directory which is needed by all users to store their temporary data in files and sub-directories. And this directory has special permissions:

# ls -ld /tmp/
drwxrwxrwt 27 root root 20480 Jun 24 14:16 /tmp/
#

Look at the last bit in permissions which is t - it is know as sticky bit and also notice all users have all the permissions on this directory. Which normally means everyone can create/delete/rename files in such a directory.

But here is where the sticky bit comes into play. When sticky bit is set on a directory, then any user can delete/rename files only owned by him/her. Try delete any file belonging to other users and you'll get permission denied error.

What's next?

That summarises the traditional file permissions on Linux. There are other ways to handle more granular permissions.

File Attributes

Can we have a file that cannot be modified, deleted, or renamed—even by root? Yes, that's where chattr comes in - it is part of e2fsprogs package on Linux.

The chattr command in Linux is used to change file attributes on a Linux file system. These attributes go beyond traditional file permissions (read/write/execute) and offer more granular control over file behaviour.

Access Control List

Can we have two different users to have read access to a file, while no one else can access it? Or want to give a specific user write access, but not change group ownership? Access Control List (ACL) is there to address these scenarios. It comes with getfacl and setfacl command-line tools to achieve granular file permissions.