On Linux, read, write, and execute have different meanings depending on whether they're permissions of a file or of a directory (a folder). In this article, we'll take a look at how they work.
File Permissions
Read Files
If a user can "read" a file, that means a program running under that user can load that data contained inside the file.
Note that this data would be physically stored in a hard disk or SSD. In modern operating systems, a program doesn't talk directly to the hard disk, they talk to the operating system and the operating system interacts with the hard disk. This means the operating system can approve or deny file access requests.
However, this doesn't actually make files "private" in any real sense. It stops other users in the same system from reading the content of the files, but these users could simply access the files from a different system if they wanted.
For example, if you have the Linux Mint installer in a USB stick, you can just plug it into a computer and make the computer boot into the installer, then access the hard disk as root from the system running in the USB stick. The root in the USB stick is a "different" user from the root in the system installed in the hard disk, but that doesn't really matter. The root user has total access to all files that the operating system can find, and because the operating system is running in a computer with a hard disk in it, it can find files there, you will be able to access them.
The main purpose of this permission is if you're running some multi-user environment (e.g. web servers, PCs used by multiple family members) and you don't want one user connected to have access to files of other users in the same server, or if
Write Files
If a user can "write" a file, that means a program running under that user can modify the data inside the file. You can open, edit, and save that file, or overwrite it.
It's sometimes useful to remove this permission from yourself from your own files. It makes them read-only, so you don't modify them by accident. It's a better idea to just have backups in case accidents happen, but not everyone is so diligent.
Execute Files
If a user can "execute" a file, that means some programs will execute it, but it's also possible for a program to execute a file that doesn't have this permission.
This permission doesn't really mean much for the operating system. All programs are data. they're algorithms saved as files. Consequently, if you can READ a file, you can't be stopped from EXECUTING the file, as all you need to do is somehow load it in memory and start executing it.
So what is the point of this permission, then?
Most programs that execute things will check this permission before executing a file. This isn't the operating system doing it. The system can't prevent files from being executed. It's the way certain programs were programmed that makes this useful.
For example, if you double click on a file on a file manager like Nemo, and the file has executable permission, Nemo will try to execute it somehow. A good example are .appimage files. An AppImage file contains an application. It's just like an .exe file on Windows. The data of the program is in there, inside the .appimage file, but in order for it to be executed, it needs to be started by ANOTHER program like the file manager, and these other programs will refuse to do this if you don't have execution permission on that file.
Similarly, if you write a script file with a shebang like #!/usr/bin/env python3, you can run it from the terminal by typing ./my-script.py if you have permission to execute it. If you don't have permission to execute it, your shell (e.g. Bash) won't let you execute the script file.
You can still execute it anyway by running the command /usr/bin/env python3 ./my-script.py. All this does is run Python and tell it to read the file and execute it. Python only needs permission to read the file. It won't check if it's a executable or not, even though what it's doing is actually executing a script file.
As you can see, the permission is mostly a matter of convenience in the context of PCs.
There are also cases where a file needs to be marked as executable because you can't really just execute it from the terminal. For example, if you have a web server running like Apache, it runs a daemon called httpd which can execute PHP files to generate webpages when someone connects to your web server. If someone accesses /index.php, Apache will execute a file called /var/www/public/index.php, for example. For security reasons, Apache won't execute a PHP file if it's not marked as executable.
Directory Permissions
Execute Directories
If a user can "execute" a directory, they have access to files inside the directory.
Without this permission, you can't, for example, use cd to change current directory to a directory you can't execute.
Read Directories
If a user can "read" a directory, that means they can list the files inside that directory.
For example, if user john can read /home/mary/, he can see that there is a file called /home/mary/diary.txt inside the directory using the command ls which lists files in a directory. However, that's the only thing he can do. He can't read the diary file unless he has read permission on the file.
Although unusual, you can have a directory with just read or execute permissions, but not both.
Read without Execute
If you can READ /home/mary/, you can call ls /home/mary/ to read the "list" of files in the directory. HOWEVER, if you don't have EXECUTE permission, you can't access the files. You can only list them. So you'll see something like this:
ls: cannot access '/home/mary/Music': Permission denied
ls: cannot access '/home/mary/Documents': Permission denied
ls: cannot access '/home/mary/Desktop': Permission denied
ls: cannot access '/home/mary/Public': Permission denied
ls: cannot access '/home/mary/Pictures': Permission denied
ls: cannot access '/home/mary/Videos': Permission denied
ls: cannot access '/home/mary/Templates': Permission denied
ls: cannot access '/home/mary/Downloads': Permission deniedYou can see what files exist, but you can't access them. There is probably no reason at all to ever have these permissions.
You also won't be able to do something like ls /home/mary/Downloads even if you have permission to READ the Downloads directory, because you don't have EXECUTE permission on the parent directory.
ls: cannot access '/home/mary/Pictures': Permission deniedExecute without Read
If you have EXECUTE permission, but not READ permission, you can't list the files, but you can still access them!
That means you can't call ls /home/mary/, but you can call cd /home/mary/.
If you have permission to EXECUTE /home/mary/Downloads/, you can call ls /home/mary/Downloads/ to list Mary's downloads, even if you can't ls /home/mary/ to list Mary's home folder files.
Note that not having READ permission doesn't mean you can't tell whether a file exists or not. If you try to access a file or directory that exists, you'll be denied permission, while a file that doesn't exist will give you a different error.
ls: cannot access '/home/mary/Non-Existing-File': No such file or directoryWrite Directories
If a user can "write" to a directory, but not "execute" it, they can't do anything with that directory.
It's kind of weird that you can read without execute, but you can't write without execute, but it's how it works for some reason.
Write and Execute Directories
If a user can "write" and "execute" a directory, that means they can create, delete, and rename files.
It may sound a bit weird that "renaming" is a permission on the directory rather than on the file itself, but the idea is that the "list of files" is the directory, while the contents inside the file is the actual file. Since renaming changes the list, but not the contents, it's a permission belonging to the directory, not the file.
Leave a Reply