Programmer, this article is for you! Grab a handful of useful information about design patterns.
Today we will talk about Linux and scripting languages. Throughout this series, we will also cover the basics of the Linux system and the Bash shell. If you are interested, we invite you to read on!
Script vs. Shell
In the Linux world, we often encounter terms like shell, script, or bash. To understand the topic well, we need to start with basic concepts. The purpose of the Linux system shell is to facilitate communication between the user and the system kernel. The kernel, on the other hand, acts as another intermediary in the system, already having access to the hardware components of our computer, responsible, for example, for managing drivers or memory. Commands serve as the highest-level interface that users interact with through the terminal.
Figure 1 – Shell and commands in the context of communication with hardware in the Linux system, source: mindmajix.com
The most commonly used shell in Linux is Bash (Bourne Again Shell), based on the Bourne shell (Sh). If bash is just a shell, acting as an abstraction layer between programs and the kernel, you may wonder: what is a script? We rush to answer – a script is simply a file that contains commands for a specific shell. So, a Bash script is just a file containing a sequence of commands for the Bash shell.
Using scripts allows for increased reliability, a higher degree of automation in the administrator’s work, and thus optimization of operations performed on the Linux system.
Script Structure
In Linux, a script begins with a so-called shebang sequence, which, in the case of Bash, looks like this: #!/bin/bash. Within the script, we can both write our own code and call programs available from the shell.
Figure 2 – Basic script in Bash. Shebang sign and the echo command invocation.
Bash does not implement a try/catch mechanism for errors, so we use error codes to communicate whether a script has completed successfully, where exit 0 indicates the script’s successful execution.
Running a Script and Permissions in the Linux System
To correctly execute a script, you need the appropriate permissions to do so. This applies to both external programs calling our script and potential users wanting to run it.
Classically, file access control in the Linux system is known as DAC – Discretionary Access Control (DAC). This model assumes that the owner of a file has control over it. In the Linux system, each file has an owner (u – user/owner), a group (g – group), and permissions that determine actions that can be performed on it, such as reading (r), writing (w), and executing (x). However, it is essential to be aware that in the Linux world, DAC is not the only option, and on this topic, we recommend the following article on SELinux.
https://github.blog/2023-07-05-introduction-to-selinux/
Coming back to permissions, the chmod command is used to modify them, allowing users to control access to their files.
Permissions in the Linux system are represented by a sequence of 9 characters, 3 for each type of permission. These represent permissions for the owner, group owner, and other users, respectively.
Figure 3 – Permissions in the Linux system, source: comentum.com
There are two ways to assign permissions in Linux using the chmod command: numerical and symbolic.
The numerical method involves assigning numerical values to individual permissions:
- 4 – Read
- 2 – Write
- 1 – Execute
The sum of numerical values provides complete information about permissions:
- 7 – Read + Write + Execute
- 6 – Read + Write 5 – Read + Execute
- 4 – Read
- 3 – Write + Execute
- 2 – Write 1 – Execute
- 0 – No permissions
Example: Granting the owner of a file read and write permissions
chmod 600 example.txt
Example: Full permissions for the file owner and read for the group and other users
chmod 744 example.txt
There are also online calculators where you choose the appropriate parameters in a convenient GUI, and the command you should execute is displayed.
Figure 4 – Linux permissions calculator, source: https://chmodcommand.com/
The symbolic method involves using specific alphabetical designations and manipulating permissions with them:
- u – Owner of the file
- g – Group owner of the file
- o – Other users
- + – Add permissions
- – – Remove permissions
- r – Read
- w – Write
- x – Execute
Example: Removing read and write permissions from the file owner
chmod u-rw example.txt
Example: Granting execution rights to other users
chmod o+x example.txt
Figure 5 – Changing script permissions in Linux
Special Permissions
It’s worth mentioning special permissions in the context of permissions in Linux, which allow for extending functionality in specific cases. There are three types of special permissions:
- SUID – an option that allows users to run a specific executable file with the permissions of its owner, not the permissions of the user launching the program at that moment. This temporarily provides elevated privileges to perform a certain action on the computer.
A classic example is the passwd program used to change passwords in the Linux system. The passwd program needs to modify the shadow file (/etc/shadow), which requires elevated privileges (both files belong to root). Therefore, the executable file passwd has the SUID bit set, allowing regular users to change their passwords without needing root access. If we decide to remove SUID and grant full permissions to the passwd file, the program will not be able to open the /etc/shadow file to make changes (as it still belongs to the root user). As a result, we will receive an access denied message when trying to run the passwd command from a user’s account.
It’s also worth noting that the passwd program checks the user’s user identifier (UID) who launches it. This check is done internally in the program’s code, ensuring that despite elevated privileges granted by SUID, the user cannot modify passwords other than their own.
In summary, SUID is used in situations where a specific user, such as root, has special privileges utilized by a particular program, privileges that an ordinary user cannot possess.
Setting SUID is manifested by the appearance of ‘s’ instead of ‘x’ in the owner’s file permissions, as observed in the image below.
Figure 6 – permissions of the /etc/passwd file, note that there is ‘rws’ instead of ‘rwx’
In the case when a file does not have the execute permission set for the owner, ‘s’ is replaced with ‘S’, indicating an error. Lack of execute permission for the owner contradicts the whole idea of SUID because a program with SUID set is executed with the owner’s rights. If the owner does not have the right to execute, there is a contradiction.
Figure 7 – Setting SUID – the difference in execution rights for the owner
- SGID – If special permissions are set for a group, there are two cases. In the case of files, similar to SUID, the program will be executed with elevated permissions, but this time, they concern the group. When SGID is set on a folder, newly created files inside that directory inherit the group affiliation from the parent directory, not from the user group creating the file. An example of use may be a folder where collaborating users save files, belonging to one group. Thanks to this, each time a user creates a file, they automatically inherit the group assigned to the parent directory.
- Sticky Bit – This is the last of the three special permission settings and concerns directories. When set, it affects shared directories, such as /tmp, where all users have the ability to write files. An important feature is that users cannot delete or modify each other’s files in these directories. Only the owner of a given resource or a user with root privileges has the ability to make such changes.
Summary
Today, we had the opportunity to familiarize ourselves with key concepts related to the Linux system and delve into details regarding assigning permissions in this environment. If you would like to learn more about Linux, we warmly invite you to a free consultation.
Sources:
- https://mindmajix.com/shell-scripting-tutorial
- https://www.comentum.com/unix-osx-permissions.html
- https://www.redhat.com/sysadmin/suid-sgid-sticky-bit
- https://linuxhandbook.com/suid-sgid-sticky-bit/
- https://security.stackexchange.com/questions/199153/why-is-linux-filesystem-considered-dac-and-not-mac
- https://github.blog/2023-07-05-introduction-to-selinux/
- https://www.linuxnix.com/suid-set-suid-linuxunix