File Permissions and Access Control Lists(ACLs) in Linux
Day 6 of 90daysofdevops
Hello Readers,
Here we are Day 6 of #90daysofdevops
👣 Topics for #day6
Basic file permissions, Special permissions
Access Control Lists (ACLs), Default ACLs
Combining file permissions and ACLs
Basic File Permissions
Every file and directory in Linux has three types of permissions: read(r), write(w), and execute(x). These permissions determine who can access the file, modify it, or execute it.
There are three types of users who can have permissions on a file are:
Owner: The user who created the file or directory.
Group: A group of users who have been given access to the file or directory.
Other: Any user who is not the owner or a member of the group.
For each of these user types, there are three types of permissions that can be provided:
Read (r): This permission allows the user to read the contents of a file or view the names of files in a directory.
Write (w): This permission allows the user to modify the contents of a file or create, move, or delete files in a directory.
Execute (x): This permission allows the user to execute a file (if it is a script) or enter a directory (if it is a directory).
The permissions are represented by a 3-digit number, where the first digit represents the owner's permissions, the second digit represents the group's permissions, and the third digit represents the permissions for other users.
For example,
I have created a file named pavan.sh and its permissions are shown below
The file has permissions "rw-r--r--" which means that the owner has read and write permissions, while the group and other users have only read permissions.
To set permissions, we can use the chmod command followed by the desired permission number and the name of the file or directory. For example, to set the permissions of a file named "pavan.sh" to "rwxrwxrwx", I used the following command:
chmod 777 pavan.sh
By understanding who has access to a file and what permissions they have, you can ensure that your files are secure and accessible only to those who need them.
Special Permissions
Linux has three special permissions: setuid, setgid, and sticky bit.
Setuid: When the setuid bit is set on an executable file, the file is executed with the privileges of the file owner, rather than the privileges of the user who is executing it. This is often used for programs that require elevated privileges to perform their tasks, such as password changing utilities.
Example:
The
passwdcommand allows users to change their passwords. However, the/etc/shadowfile, which contains the password hashes, is only readable by the root user.To allow non-root users to change their passwords, the
passwdcommand is setuid to the root user, so it can access the/etc/shadowfile.Setgid: When the setgid bit is set on a directory, any new files or directories created in that directory inherit the group ownership of the parent directory, rather than the group ownership of the user who created the file or directory. This is useful for ensuring that files created in a shared directory are accessible to all members of a group.
Example:
A development team needs to work on a project directory, but they all have different group memberships. To ensure that all files created in the project directory have the correct group ownership, the project directory is setgid to the group that the team members belong to. This means that any files or directories created within the project directory will have the group ownership of the project directory, rather than the group ownership of the user who created them.
Sticky bit: When the sticky bit is set on a directory, only the owner of a file can delete or rename that file, even if other users have write permissions on the directory. This is useful for ensuring that files in a shared directory are not accidentally deleted or modified by other users.
Example:
A shared directory on a file server allows multiple users to upload and download files. To prevent users from accidentally deleting files that belong to other users, the shared directory is set with the sticky bit. This means that users can only delete files that they own, while files owned by other users cannot be deleted, even if the user has write permissions to the directory.
These special permissions are represented by additional characters in the file permissions string.
Access Control Lists (ACLs)
Access Control Lists (ACLs) are a more fine-grained way of controlling access to files and directories than traditional/normal file permissions. While traditional file permissions allow you to control access based on the user's relationship to the file (owner, group, or other), ACLs allow you to control access based on specific users and groups.
With ACLs, you can grant or deny permissions to individual users or groups on a per-file or per-directory basis. This means that you can give different permissions to different users for the same file or directory, allowing for much greater flexibility in access control.
ACLs are represented by a set of rules that are stored in the file system's metadata. Each rule consists of a user or group identifier, a set of permissions, and a type of permission (allow or deny).
To view the ACLs for a file or directory, you can use the getfacl command.
For example, to view the ACLs for a file named "pavan.sh", I used the following command:
getfacl pavan.sh
To set ACLs, you can use the setfacl command.
For example, to grant read and write access to a user named "jdoe" on a file named "pavan.sh", you would use the following command:
setfacl -m u:pavan07:rw pavan.sh
Here is a breakdown of the command:
setfacl: the command to modify the ACL of a file or directory-m: the option to modify the ACLu:pavan07:rw: the specification of the userpavan07and the permissions we want to grant (rwfor read and write access)pavan.sh: the file we want to modify the ACL for.
So, after running this command, the user pavan07 will have read and write access to the file pavan.sh, in addition to any other access permissions that are already in place for the file.
Default ACLs
Default ACLs are used in Linux to set a default ACL for a directory.
Default ACLs are applied to all files and directories created within that directory, ensuring that they have the same ACLs as the parent directory.
Example of how default ACLs work:
Suppose we have a directory called /home/pavan07, and we want to set a default ACL for this directory. We can use the setfacl command with the -d option to set a default ACL for the directory:
setfacl -d -m u:pavan07:rw /home/pavan07
This command sets the default ACL for the directory /home/pavan07 to grant user pavan07 read and write access to any files or directories created within the directory.
Now, suppose we create a file called harsha.txt the directory /home/pavan07. The file will inherit the default ACL from the parent directory, /home/pavan07. In this case, harsha.txt will have the same ACL as /home/pavan07, which grants user pavan07 read and write access.
If we create a subdirectory called dir2 within /home/pavan07, the subdirectory will also inherit the default ACL from the parent directory. In this case, dir2 will have the same ACL as /home/pavan07, which grants user pavan07 read and write access.
By using default ACLs, we can ensure that all files and directories created within a directory have the same set of permissions, regardless of who created them. This can be useful in situations where multiple users need to collaborate on a project and need consistent permissions across all files and directories.
Combining file permissions and ACLs
File permissions provide a basic level of access control based on the owner, group, and other users, while ACLs provide more granular control over file access by allowing you to specify access permissions for individual users and groups.
When both file permissions and ACLs are used together, the permissions are evaluated in a specific order to determine the final access control for a user or group. The order of evaluation is as follows:
If a user is the owner of the file, then the owner permissions apply.
If the user is not the owner of the file, but belongs to the group that owns the file, then the group permissions apply.
If the user is not the owner of the file and does not belong to the group that owns the file, then the other permissions apply.
If there is a matching ACL entry for the user or group, then the ACL permissions apply, overriding any matching file permissions.
Example:
Suppose we have a file called myfile with the following file permissions:
-rw-r----- 1 user1 group1 0 Mar 30 11:59 myfile
This file is owned by user1 and belongs to group1.
The owner (user1) has read and write access to the file, while members of the group (group1) have only read access. All other users have no access to the file.
Now, suppose we add an ACL entry to grant user2 write access to the file:
setfacl -m u:user2:rw myfile
After adding this ACL entry, user2 now has read and write access to the file, even though they are not the owner of the file and do not belong to the group that owns the file.
In this way, combining file permissions and ACLs allows us to provide fine-grained control over file access, granting specific users or groups access to a file or directory while still maintaining basic permissions based on ownership and group membership.
Thank you for reading my Blog. I hope you have learnt something from it! If you find this blog helpful, please like, share, and follow me for more interesting posts like this in the future.
Please navigate to my GitHub Repo: GitHub Repo Link
to check my solutions for the tasks of 90daysofdevops Challenge.