Hi all. This is a translation of an article from the book RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 and EX300.
From the following: I hope the article will be useful not only for beginners, but will also help more experienced administrators streamline their knowledge.
So, let's go.
To access files in Linux, permissions are used. These permissions are assigned to three objects: the file owner, the group owner, and another object (that is, everyone else). In this article, you'll learn how to apply permissions.
This article begins with an overview of the basic concepts, followed by a discussion of Special permissions and Access Control Lists (ACLs). At the end of this article, we cover setting default permissions via umask, as well as managing extended user attributes.
File ownership management
Before discussing permissions, you should be aware of the role of file and directory owner. Ownership of files and directories is vital to dealing with permissions. In this section, you will first learn how you can see the owner. You will then learn how to change the group owner and user for files and directories.
Displaying the owner of a file or directory
In Linux, every file and every directory has two owners: a user and a group owner.
These owners are set when a file or directory is created. The user who creates the file becomes the owner of that file, and the primary group that the same user belongs to also becomes the owner of that file. To determine if you, as a user, have permission to access a file or directory, the shell checks for ownership.
This happens in the following order:
- The shell checks to see if you are the owner of the file you want to access. If you are the owner, you get permissions and the shell stops checking.
- If you are not the owner of the file, the shell will check to see if you are a member of a group that has permissions on the file. If you are a member of this group, you will access the file with the permissions that the group has set, and the shell will stop checking.
- If you are neither a user nor the owner of a group, you are given the rights of other users (Other).
To see the current owner assignments, you can use the command Ls -l. This command shows the user and owner of the group. Below you can see the owner settings for directories in the /home directory.
[root@server1 home]# ls -l
total 8
drwx------. 3 bob bob 74 Feb 6 10:13 bob
drwx------. 3 caroline caroline 74 Feb 6 10:13 caroline
drwx------. 3 fozia fozia 74 Feb 6 10:13 fozia
drwx------. 3 lara lara 74 Feb 6 10:13 lara
drwx------. 5 lisa lisa 4096 Feb 6 10:12 lisa
drwx------. 14 user user 4096 Feb 5 10:35 user
With the command ls you can display the owner of files in a given directory. Sometimes it can be useful to get a list of all files on the system that have a given user or group as the owner. For this you can use find. Argument find-user can be used for this purpose. For example, the following command lists all files that are owned by the user linda:
find / -user lindaYou can also use find to search for files that have a certain group as their owner.
For example, the following command searches for all files belonging to the group users:
find / -group usersChange in ownership
To apply the appropriate permissions, the first thing to consider is ownership. There is a command for this chown. The syntax of this command is easy to understand:
chown ΠΊΡΠΎ ΡΡΠΎFor example, the following command changes the owner of the /home/account directory to the user linda:
chown linda /home/accountTeam chown has several options, one of which is particularly useful: -R. You can guess what it does because this option is available for many other commands as well. This allows you to recursively set the owner, which allows you to set the owner of the current directory and everything below. The following command changes ownership of the /home directory and everything below it to the linda user:
Now the owners look like this:
[root@localhost ~]# ls -l /home
total 0
drwx------. 2 account account 62 Sep 25 21:41 account
drwx------. 2 lisa lisa 62 Sep 25 21:42 lisa
Let's execute:
[root@localhost ~]# chown -R lisa /home/account
[root@localhost ~]#
Now the user lisa has become the owner of the account directory:
[root@localhost ~]# ls -l /home
total 0
drwx------. 2 lisa account 62 Sep 25 21:41 account
drwx------. 2 lisa lisa 62 Sep 25 21:42 lisa
Change the owner of a group
There are two ways to change the ownership of a group. You can do this using chown, but there is a special command named chgrpthat does the job. If you want to use the command chown, use . or : in front of the group name.
The following command changes any owner of the /home/account group to the account group:
chown .account /home/account
You can use chown to change the owner of a user and/or group in several ways. Here are some examples:
- chown lisa myfile1 sets the user lisa as the owner of myfile1.
- chown lisa.sales myfile sets the user lisa as the owner of the myfile file, and also sets the sales group as the owner of the same file.
- chown lisa:sales myfile the same as the previous command.
- chown .sales myfile sets the sales group as the owner of myfile without changing the owner of the user.
- chown :sales myfile the same as the previous command.
You can use the command chgrpto change the owner of the group. Consider the following example, where you can use chgrp set the owner of the account directory to the sales group:
chgrp .sales /home/accountAs in the case of chown, you can use the option -R Ρ chgrp, as well as recursively change the owner of the group.
Understanding the Default Owner
You may have noticed that when a user creates a file, the default ownership is applied.
The user who creates the file automatically becomes the owner of that file, and that user's primary group automatically becomes the owner of that file. This is usually the group that is listed in the /etc/passwd file as the user's primary group. However, if the user is a member of more than one group, the user can change the effective primary group.
To show the current effective primary group, the user can use the command groups:
[root@server1 ~]# groups lisa
lisa : lisa account sales
If the current linda user wants to change the effective primary group, he will use the command newgrpfollowed by the name of the group he wants to set as the new effective primary group. After using the command newgrp the primary group will be active until the user enters a command exit or not log out.
The following shows how the user linda uses this command, with sales as the primary group:
lisa@server1 ~]$ groups
lisa account sales
[lisa@server1 ~]$ newgrp sales
[lisa@server1 ~]$ groups
sales lisa account
[lisa@server1 ~]$ touch file1
[lisa@server1 ~]$ ls -l
total 0
-rw-r--r--. 1 lisa sales 0 Feb 6 10:06 file1
After changing the effective primary group, all new files created by the user will have that group as the group owner. To revert to the original primary group setting, use exit.
To be able to use the command newgrp, the user must be a member of the group they want to use as the primary group. In addition, a group password can be used for a group using the command gpasswd. If the user uses the command newgrpbut is not a member of the target group, the shell prompts for the group's password. After you enter the correct group password, a new effective primary group will be established.
Fundamental rights management
The Linux permission system was invented in the 1970s. Since the computing needs were limited in those years, the basic permission system was quite limited. This permission system uses three permissions that can be applied to files and directories. In this section, you will learn how to use and change these permissions.
Understanding Read, Write, and Execute Permissions
Three basic permissions allow you to read, write, and execute files. The effect of these permissions differs when applied to files or directories. For a file, the read permission gives you the right to open the file for reading. Therefore, you can read its content, but that means your computer can open the file to do something with it.
A program file that needs access to a library must, for example, have read access to that library. It follows that the read permission is the most basic permission you need to work with files.
When applied to a directory, reading allows you to display the contents of that directory. You should be aware that this permission does not allow you to read the files in the directory. The Linux permission system does not know inheritance, and the only way to read a file is to use read permissions on that file.
As you can probably guess, write permission, if applied to a file, allows writing to the file. In other words, it allows you to change the contents of existing files. However, it does not allow you to create or delete new files or change file permissions. To do this, you need to give write permission to the directory where you want to create the file. In directories, this permission also allows you to create and delete new subdirectories.
Execute permission is what you need to execute the file. It will never be installed by default, which makes Linux almost completely immune to viruses. Only someone with write permissions on the directory can apply execute permission.
The following summarizes the use of basic permissions:
Using chmod
The command is used to manage permissions. chmod... Using chmod you can set permissions for the user (user), groups (group) and others (other). You can use this command in two modes: relative mode and absolute mode. In absolute mode, three digits are used to set basic permissions.
When setting permissions, calculate the value you need. If you want to set read/write/execute for user, read/execute for group, and read/execute for others in /somefile then you use the following command chmod:
chmod 755 /somefileWhen you use chmod in this way, all current permissions are replaced by the permissions you set.
If you want to change the permissions relative to the current permissions, you can use chmod in relative mode. Using chmod in relative mode you work with three indicators to indicate what you want to do:
- First you specify who you want to change permissions for. To do this, you can choose between user (u), group (g) and others (o).
- You then use a statement to add or remove permissions from the current mode, or set them absolutely.
- At the end you use r, w ΠΈ xto specify which permissions you want to set.
When changing permissions in relative mode, you can skip the "to" part to add or remove the permission for all objects. For example, this command adds execute permission for all users:
chmod +x somefileWhen working in relative mode, you can also use more complex commands. For example, this command adds write permission to a group and removes read permission for others:
chmod g+w,o-r somefileUsing chmod -R o+rx /data you set execute permission for all directories as well as files in the /data directory. To set execute permission only for directories and not for files, use chmod -R o+ rX /data.
The uppercase X ensures that files do not get execute permission unless the file has already set execute permission for some objects. This makes X a smarter way to deal with execute permissions; this will avoid setting this permission on files where it is not needed.
Extended rights
In addition to the basic permissions you just read about, Linux also has a set of advanced permissions. These are not the permissions you set by default, but sometimes they provide a useful addition. In this section, you'll learn what they are and how to set them up.
Understanding SUID, GUID, and Sticky Bit Extended Permissions
There are three advanced permissions. The first of these is the permission to set a user identifier (SUID). In some special cases, you can apply this permission to executable files. By default, a user who runs an executable runs that file with their own permissions.
For ordinary users, this usually means that the use of the program is limited. However, in some cases, the user needs special permissions, only to perform a specific task.
Consider, for example, a situation where a user needs to change their password. To do this, the user must write their new password to the /etc/shadow file. However, this file is not writable by non-root users:
root@hnl ~]# ls -l /etc/shadow
----------. 1 root root 1184 Apr 30 16:54 /etc/shadow
The SUID permission offers a solution to this problem. The /usr/bin/passwd utility uses this permission by default. This means that when changing the password, the user temporarily becomes root, which allows him to write to the /etc/shadow file. You can see the SUID permission with Ls -l How s in a position where you would normally expect to see x for custom permissions:
[root@hnl ~]# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 32680 Jan 28 2010 /usr/bin/passwd
The SUID permission may look useful (and in some cases it is), but at the same time it is potentially dangerous. If not applied correctly, you can accidentally give away root permissions. Therefore, I recommend using it only with the utmost care.
Most administrators will never need to use it; you will only see it in some files where the operating system should set it by default.
The second special permission is the group identifier (SGID). This permission has two effects. When applied to an executable file, it gives the user who executes the file the permissions of the file's group owner. So SGID can do more or less the same thing as SUID. However, SGID is practically not used for this purpose.
As with SUID permission, SGID is applied to some system files as a default setting.
When applied to a directory, the SGID can be useful because you can use it to set the default group owner for files and subdirectories created in that directory. By default, when a user creates a file, their effective primary group is set as the group owner for that file.
This is not always very useful, especially since Red Hat/CentOS users have their primary group set to a group with the same name as the user, and of which the user is the only member. Thus, by default, the files that the user creates will be shared in bulk.
Imagine a situation where users linda and lori work in accounting and are members of a group account. By default, these users are members of a private group of which they are the only member. However, both users are members of the account group, but also as a secondary group parameter.
The default situation is that when any of these users create a file, the primary group becomes the owner. Therefore, by default, linda cannot access files created by lori, and vice versa. However, if you create a shared group directory (say /groups/account) and ensure that the SGID permission is applied to that directory and that the group account is set as the group owner for that directory, all files created in that directory and all of its subdirectories , also get the group account as the group owner by default.
For this reason, the SGID permission is a very useful permission to set on public group directories.
SGID permission shown in output Ls -l How s at the position where you would normally find permission to execute a group:
[root@hnl data]# ls -ld account
drwxr-sr-x. 2 root account 4096 Apr 30 21:28 account
The third of the special permissions is the sticky bit. This permission is useful for protecting files from accidental deletion in an environment where multiple users have write access to the same directory. If a sticky bit is used, a user can only delete a file if they are the user owner of the file or directory that contains the file. For this reason, it is used as the default permission for the /tmp directory and can be useful for public group directories as well.
Without the sticky bit, if the user can create files in a directory, they can also delete files from that directory. In a public group environment, this can be annoying. Imagine the users linda and lori, who both have write permissions to the /data/account directory and get those permissions by being members of the account group. Therefore, linda can delete files created by lori and vice versa.
When you apply the sticky bit, the user can only delete files if one of the following conditions is true:
- The user is the owner of the file;
- The user is the owner of the directory where the file is located.
Using Ls -l, you can see the sticky bit as t in the position where you would normally see execution permission for others:
[root@hnl data]# ls -ld account/
drwxr-sr-t. 2 root account 4096 Apr 30 21:28 account/
Applying extended rights
To apply SUID, SGID and sticky bit you can also use chmod. SUID has a numeric value of 4, SGID has a numeric value of 2, and sticky bit has a numeric value of 1.
If you want to apply these permissions, you need to add a four digit argument to chmod, whose first digit refers to special permissions. The following line, for example, will add SGID permission to the directory and set rwx for user and rx for group and others:
chmod 2755 /somedirThis is rather impractical if you need to see the current permissions that are set before working with chmod in absolute mode. (You run the risk of overwriting permissions if you don't.) So I recommend running in relative mode if you need to apply any of the special permissions:
- For SUID use chmod u+s.
- For SGID use chmod g+s.
- For sticky bit use chmod +t, followed by the name of the file or directory for which you want to set permissions.
The table summarizes everything you need to know about managing special permissions.
Example of working with special rights
In this example, you use special permissions to make it easier for group members to share files in the shared group directory. You assign the ID bit to the set group ID as well as the sticky bit, and you see that once they are set, features are added to make it easier for group members to work together.
- Open a terminal where you are the linda user. You can create a user with the command Linda, add password passwd Linda.
- Create the /data directory in the root and the /data/sales subdirectory with the command mkdir -p /data/sales... Execute cd /data/salesto go to the sales directory. Complete touch linda1 ΠΈ touch linda2to create two empty files owned by linda.
- Perform su-lisa to switch the current user to the user lisa, who is also a member of the sales group.
- Perform cd /data/sales and from that directory execute Ls -l. You will see two files that were created by the linda user and belong to the linda group. Complete rm -f linda*. This will remove both files.
- Perform touch lisa1 ΠΈ touch lisa2to create two files that are owned by the user lisa.
- Perform his - to elevate your privileges to root.
- Perform chmod g+s,o+t /data/salesto set the group identifier (GUID) bit as well as the sticky bit in the shared group directory.
- Perform su-linda. Then do touch linda3 ΠΈ touch linda4. You should now see that the two files you created are owned by the sales group, which is the group owner of the /data/sales directory.
- Perform rm -rf lisa*. The sticky bit prevents these files from being deleted on behalf of the linda user, since you are not the owner of these files. Note that if the linda user is the owner of the /data/sales directory, they can delete these files anyway!
ACL management (setfacl, getfacl) in Linux
Even though the extended permissions discussed above add useful functionality to the way Linux handles permissions, it doesn't allow you to grant permissions to more than one user or group in the same file.
Access control lists offer this feature. In addition, they allow administrators to set default permissions in a complex way, where the set permissions may vary from directory to directory.
Understanding ACLs
Although the ACL subsystem adds great functionality to your server, it has one disadvantage: not all utilities support it. Therefore, you may lose your ACL settings when you copy or move files, and your backup software may fail to back up your ACL settings.
The tar utility does not support ACLs. To make sure ACL settings are not lost when you create a backup, use star instead of tar. star works with the same options as tar; it just adds support for ACL settings.
You can also back up ACLs with getfacl, which can be restored using the setfacl command. To create a backup, use getfacl -R /directory > file.acls. To restore settings from a backup file, use setfacl --restore=file.acl.
Lack of support by some tools shouldn't be a problem. ACLs are often applied to directories as a structural measure rather than to individual files.
Therefore, there will not be many of them, but only a few, applied in smart places in the file system. Therefore, restoring the original ACLs you worked with is relatively easy, even if your backup software doesn't support them.
Preparing the file system for ACLs
Before you start working with ACLs, you may need to prepare your file system to support ACLs. Because file system metadata needs to be extended, there is not always default support for ACLs in the file system. If you get an "operation not supported" message when setting up ACLs for a file system, your file system may not support ACLs.
To fix this you need to add the option acl mount in /etc/fstab so that the filesystem is mounted with ACL support by default.
Changing and viewing ACL settings with setfacl and getfacl
To set an ACL you need the command setfacl. To see the current ACL settings, you need getfacl. Team Ls -l does not show any existing ACLs; it just shows a + after the permission list, which indicates that the ACLs apply to the file as well.
Before setting up ACLs, it is always a good idea to show the current ACL settings with getfacl. In the example below, you can see the current permissions, as shown with Ls -l, and also as shown with getfacl. If you look closely enough, you will see that the information shown is exactly the same.
[root@server1 /]# ls -ld /dir
drwxr-xr-x. 2 root root 6 Feb 6 11:28 /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
As a result of executing the command getfacl below you can see that the permissions are shown for three different objects: user, group and others. Now let's add an ACL to give read and execute permissions to the sales group as well. command for this setfacl -mg:sales:rx /dir. In this team -m indicates that the current ACL settings need to be changed. After that g:sales:rx tells the command to set the read-execute ACL (rx) for the group (g) sales. Below you can see what the command looks like, as well as the output of the getfacl command after changing the current ACL settings.
[root@server1 /]# setfacl -m g:sales:rx /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
group:sales:r-x
mask::r-x
other::r-x
Now that you understand how to set up a group ACL, it's easy to understand ACLs for users and other users. For example, the command setfacl -mu:linda:rwx /data gives permissions to the user linda in the /data directory without making him the owner or changing the assignment of the current owner.
Team setfacl has many features and options. One option is especially important, the parameter -R. If used, the option makes the ACL set for all files and subdirectories that currently exist in the directory where you set the ACL. It is recommended that you always use this option when changing ACLs for existing directories.
Working with Default ACLs
One of the benefits of using ACLs is that you can grant permissions to multiple users or groups in a directory. Another benefit is that you can enable inheritance by working with the default ACLs.
By setting the default ACL, you determine the permissions that will be set for all new items created in the directory. Be aware that the default ACL does not change permissions on existing files and subdirectories. To change them, you need to add a normal ACL too!
This is important to know. If you want to use an ACL to configure multiple users or groups to access the same directory, you must set the ACL twice. First use setfacl -R -mto change ACLs for current files. Then use setfacl-md:to take care of all new elements that will also be created.
To set the default ACL you just need to add the option d after option -m (order matters!). So use setfacl -md:g:sales:rx /dataif you want group sales to read and execute whatever is ever created in the /data directory.
When using default ACLs, it may also be useful to set ACLs for others. This usually doesn't make much sense because you can also change the permissions for others using chmod. However, what you cannot do with chmod, is to specify the rights that must be granted to other users for every new file that is ever created. If you want to prevent others from getting any permissions on anything created in /data for example use setfacl -md:o::- /data.
ACLs and normal permissions are not always well integrated. Problems can arise if you apply a default ACL to a directory, then items are added to that directory, and then try to change the normal permissions. Changes that apply to regular permissions will not be well reflected in the ACL overview. To avoid problems, set normal permissions first, then set the default ACLs (and try not to change them again after that).
Example of Elevated Rights Management Using ACLs
In this example, you will continue with the /data/account and /data/sales directories you created earlier. In the previous examples, you ensured that the sales group has permissions on /data/sales and the account group has permissions on /data/account.
First, make sure the account group gets read permissions on the /data/sales directory and the sales group gets read permissions on the /data/account directory.
You then set default ACLs to make sure all new files have the correct permissions set for all new items.
- Open a terminal.
- Perform setfacl -mg:account:rx /data/sales ΠΈ setfacl -mg:sales:rx /data/account.
- Perform getfaclto make sure the permissions were set the way you wanted.
- Perform setfacl -md:g:account:rwx,g:sales:rx /data/salesto set the default ACL for the sales directory.
- Add a default ACL for the /data/account directory using setfacl -md:g:sales:rwx,g:account:rx /data/account.
- Verify that the ACL settings are in effect by adding a new file to /data/sales. Complete touch /data/sales/newfile and execute getfacl /data/sales/newfile to check current permissions.
Setting default permissions with umask
Above, you learned how to work with default ACLs. If you are not using an ACL, there is a shell option that determines the default permissions you will get: umask (reverse mask). In this section, you will learn how to change the default permissions with umask.
You may have noticed that when you create a new file, some default permissions are set. These permissions are determined by the setting umask. This shell setting applies to all users at logon. In parameter umask a numeric value is used, which is subtracted from the maximum permissions that can be automatically set for the file; the maximum setting for files is 666 and for directories is 777.
However, some exceptions apply to this rule. You can find a complete overview of settings umask in the table below.
Of the numbers used in umask, as in the case of numeric arguments for the command chmod, the first digit refers to the user's permissions, the second digit refers to the group's permissions, and the last refers to the default permissions set for others. Meaning umask the default 022 gives 644 for all new files and 755 for all new directories created on your server.
Complete overview of all numerical values umask and their results in the table below.
An easy way to see how the umask setting works is as follows: start with the file's default permissions set to 666 and subtract the umask to get the effective permissions. Do the same for the directory and its default permissions of 777.
There are two ways to change the umask setting: for all users and for individual users. If you want to set the umask for all users, you must ensure that the umask setting is taken into account when starting shell environment files, as specified in /etc/profile. The correct approach is to create a shell script called umask.sh in the /etc/profile.d directory and specify the umask you want to use in that shell script. If the umask is changed in this file, it is applied to all users after logging into the server.
An alternative to setting the umask via /etc/profile and related files, where it applies to all users logging in, is to change the umask settings in a file called .profile that is created in each user's home directory.
The settings applied in this file apply only to the individual user; hence this is a good method if you need more detail. I personally like this feature to change the default umask for the root user to 027 while normal users are running with the default umask of 022.
Working with extended user attributes
This is the final section on Linux permissions.
When working with permissions, there is always a relationship between a user or group object and the permissions that user or group objects have on a file or directory. An alternative method to protect files on a Linux server is to work with attributes.
Attributes do their job regardless of the user accessing the file.
As with ACLs, file attributes may need to include the option mount.
This is an option user_xattr. If you get an "operation not supported" message when working with extended user attributes, be sure to set the parameter mount in /etc/fstab.
Many attributes are documented. Some attributes are available but not implemented yet. Don't use them; they won't bring you anything.
Below are the most useful attributes you can apply:
A This attribute ensures that the file's file access time does not change.
Typically, each time a file is opened, the file's access time must be recorded in the file's metadata. This negatively impacts performance; so for files that are regularly accessed, the attribute A can be used to disable this feature.
a This attribute allows you to add but not remove a file.
c If you are using a file system that supports volume-level compression, this file attribute ensures that the file is compressed the first time the compression mechanism is enabled.
D This attribute ensures that changes to files are written to disk immediately rather than cached first. This is a useful attribute on important database files to make sure they don't get lost between the file cache and the hard drive.
d This attribute ensures that the file will not be saved in backups where the dump utility is used.
I This attribute enables indexing for the directory in which it is enabled. This provides faster file access for primitive filesystems like Ext3 that don't use the B-tree database for fast file access.
i This attribute makes the file immutable. Therefore, no changes can be made to the file, which is useful for files that need additional protection.
j This attribute ensures that, on an ext3 file system, the file is first written to the journal and then to data blocks on the hard disk.
s Overwrite the blocks in which the file was saved to 0s after deleting the file. This ensures that a file cannot be restored once it has been deleted.
u This attribute stores information about the deletion. This allows you to develop a utility that works with this information to rescue deleted files.
If you want to apply the attributes, you can use the command chattr. For example, use chattr +s somefileto apply attributes to somefile. Need to remove an attribute? Then use chattr -s somefileand it will be removed. To get an overview of all attributes that are currently applied, use the command lsattr.
Summary
In this article, you learned how to work with permissions. You read about the three basic permissions, advanced permissions, and how to apply ACLs on a file system. You also learned how to use the umask option to apply default permissions. At the end of this article, you learned how to use user-extended attributes to apply an additional layer of file system security.
If you liked this translation, then please write about it in the comments. There will be more motivation to make useful translations.
Corrected some typos and grammatical errors in the article. Reduced some bulky paragraphs into smaller ones for better readability.
Instead of "Only someone with administrative rights to the directory can apply execute permission." fixed to "Only someone with write permissions on the directory can apply execute permission.", which would be more correct.
Thanks for the comments .
Replaced:
If you are not the owner of the user, the shell will check to see if you are a member of a group, also known as the group of the file.To:
If you are not the owner of the file, the shell will check to see if you are a member of a group that has permissions on the file. If you are a member of this group, you will access the file with the permissions that the group has set, and the shell will stop checking.Thank you for your comment
Source: habr.com