In Linux-like systems there are many security mechanisms that allow to authenticate the user, to delimit the working environment, to filter system events or network packets at the lower and upper levels. One of them solves issues related to the distribution of rights between users of the same OS - the mechanism of access rights differentiation. There are many different variants of their implementation, however, in Linux and Windows, by default, DAC is used.
If this combination of symbols is still unclear to you, we will understand it in more detail below in the article. We will also consider a rather simple way of setting it up.
What is DAC and how do I set it up?
In order to effectively differentiate user rights, three basic models have been developed that define the possibility of access from subjects (users) to objects (files): DAC, MAC, RBAC.
DAC or discretionary access rights delimitation is a mechanism in which file attributes and user rights define the delimitation rules. It can be represented as a matrix, where sub-objects and objects are displayed in rows and columns respectively. And in their intersections are defined the rights that users have with respect to a particular file.
In practice, it works as follows. When a file is created, it is assigned basic attributes that are written in addition to the file's meta-data: owner, owner's group, as well as rights for these categories and other users.
The screenshot shows rwx triplets, which just define access categories for the owner, its group and others. In the process of requesting a file, the rights of the subobject and the object are compared, if the user has access, the kernel will perform an action on the file, otherwise it will deny the access.
However, you may wonder, what if three categories are not enough for you? For example, you have contractors that perform tasks on your infrastructure. And instead of 32 files that users in the owner group have access to, you need to provide access to 3. What to do? Most Linux distributions have ACL lists. These are designed to grant rights by name, minimising the disadvantage of granting rights to a group of users.
To work with this solution you need to install the packages, for most systems they are already in the standard repositories:
apt update && apt install acl -y For rpm-like systems you can use another command:
dnf install acl -y 
After that, file attributes will be managed by two basic commands getfacl and setfacl. Let's create any file and view its permissions.
If you don't have sufficient resources than you can perform actions on powerful cloud servers. Serverspace provides isolated VPS / VDS servers for common and virtualize usage.
To do this, we use the && operand, which will allow us to execute two commands at once instead of one:
touch 1.txt && getfacl 1.txt 
The file contains classic permissions for the standard 3 user groups. But if you write a command with stefacl options, you can add both an individual user and the whole non-owner group.
setfacl -m group:users:rwx 1.txt 
The syntax is a set of commands to invoke a utility with options:
- setfacl - a utility to set attributes to a file;
- -m - option specifying the functions to be used when working with the file;
- group - the type of the subject to which the rights are granted;
- users - name of the subobject type, in this case the name of the group;
- rwx - permissions to be granted to the sub-object;
- 1.txt - name of the file for issuing attributes.
Now it contains both standard permissions and a custom one for users of the users group, where they can access the file with full permissions. We may have overreacted by giving full permissions. Let's remove one or all of the new rules.
setfacl -x group:users 1.txt 
If there is a need to remove all permissions, we will use the command - it will reset all previously entered ACL rules:
setfacl -b 1.txt This works in a similar way with directories, except that the syntax is slightly modified. The d option is specified first, followed by the same rule with the path.
setfacl -m d:u:koldek:rwx ~/
Now the root directory can be accessed not only by root, but also by the user koldek. Of course, you shouldn't do it this way, but it's good for demonstration purposes. And if you need to recursively change permissions for the directory and all subfolders, you can change permissions recursively:
setfacl -r -m d:u:koldek:rwx ~/ However, this advanced DAC mechanism has its disadvantages, since not all distributions have the ACL module pre-installed, the new attributes will not be read. The same goes for transmission media, not all distributions have the ability to package the necessary labels. There may be problems with indexing, when searching for files, because ACL gives additional load and is slower than standard discretionary lists.
It is up to you whether you use it on your system or not, but this flexible tool adds great functionality to your existing discretionary control mechanism.
