Linux rights (chown, chmod, SUID, GUID, sticky bit, ACL, umask)
Hello. This is a translation of an article from RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 and EX300.
From myself: I hope the article will be useful not only for beginners, but also will help more experienced administrators organize their knowledge.
So let's go.
To access files on Linux, permissions are used. These permissions are assigned to three objects: a file, a group, and another object (that is, everyone else). In this article, you will learn how to apply permissions.
The article begins with a review of the basic concepts, after which special permissions and access control lists (ACLs) are discussed. At the end of this article, we will look at setting default permissions through umask, as well as managing advanced user attributes.
Before discussing permissions, you should be aware of the role of the owner of the file and directory. Owning files and directories is vital to working 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.
On Linux, each file and each directory has two owners: a user and a group.
These owners are set when the file or directory is created. The user who creates the file becomes the owner of this file, and the primary group, which includes the same user, also becomes the owner of this file. To determine whether you as a user have access rights to a file or directory, the shell checks its ownership.
This happens in the following order:
To see the current owner assignments, you can use the ls -l command . This command shows the user and owner group. Below you can see the owner settings for directories in the / home directory.
Using the ls command, you can display the owner of the files in this directory. Sometimes it may be useful to get a list of all the files in the system in which the user or group is specified as the owner. You can use find for this . The find -user argument can be used for this purpose. For example, the following command shows all files that have the linda user specified as the owner:
You can also use find to search for files in which a particular group owns them.
For example, the following command searches for all files belonging to the users group:
To apply permissions, the first thing to consider is ownership. There is a chown command for this. The syntax of this command is easy to understand:
For example, the following command changes the owner of the / home / account directory to user linda:
The chown command has several options, one of which is especially useful: -R . You can guess what it does, because this option is also available for many other teams. 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 the owner for the / home directory and everything below it to lisa:
Now the owners look like this:
Run:
Now lisa has become the owner of the account directory:
There are two ways to change group ownership. You can do this using chown , but there is a special command called chgrp that does the job. If you want to use the chown command , use . or : before the name of the group.
The following command changes any owner of the / home / account group to the account group:
You can use chown to change the owner of a user and / or group in several ways. Here are some examples:
You can use the chgrp command to change the group owner. Consider the following example, where you can use chgrp to set the sales group as the owner of the account directory:
As with chown , you can use the -R option with chgrp , as well as recursively change the group owner.
You may notice that when the user creates the file, default ownership is applied.
The user who creates the file automatically becomes the owner of this file, and the main group of this user automatically becomes the owner of this file. This is usually a group that is specified in the / etc / passwd file as the user's main group. However, if the user is a member of several groups, he can change the effective core group.
To show the current effective primary group, the user can use the groups command:
If the current user linda wants to change the effective primary group, he will use the newgrp command, followed by the name of the group that he wants to set as the new effective primary group. After using the newgrp command, the primary group will be active until the user issues the exit command or logs out.
The following shows how lisa uses this command so that the sales group becomes the primary group:
After changing the current main group, all new files created by the user will receive this group as the owner group. To return to the initial setting of the primary group, use exit .
To be able to use the newgrp command, the user must be a member of the group that he wants to use as primary. In addition, the group password can be used for the group using the gpasswd command. If the user uses the newgrp command but is not a member of the target group, the shell requests the group password. After you enter the correct group password, a new effective primary group will be set.
The Linux permission system was invented in the 1970s. Since computing needs were limited in those years, the basic permission system was rather 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.
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, read permission gives you the right to open the file for reading. Therefore, you can read its contents, but this means that your computer can open the file to do something with it.
A program file that needs access to a library should, for example, have read access to that library. It follows that read permission is the most basic permission you need to work with files.
For a directory, reading allows you to display the contents of that directory. You should know that this permission does not allow you to read files in a directory. Linux permissions do not know inheritance, and the only way to read a file is to use read permissions for that file.
As you can probably guess, the write permission, if applied to the file, allows you to write to the file. In other words, it allows you to modify the contents of existing files. However, it does not allow creating or deleting new files or changing 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.
Execution 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 to the directory can apply permission to execute.
The following summarizes the use of basic permissions:
To manage rights, use the chmod command . When using chmod, you can set permissions for the user (user), group (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 the basic permissions.
When setting permissions, calculate the value you need. If you want to set read, write and execute for the user, read and execute for the group, and read and execute for others in the / somefile, then you use the following chmod command :
When you use chmod in this way, all current permissions are replaced by the permissions you set.
If you want to change permissions relative to current permissions, you can use chmod in relative mode. When using chmod in relative mode, you are working with three indicators to indicate what you want to do:
When changing permissions in relative mode, you can skip the “to” part to add or remove permission for all objects. For example, this command adds execution permission for all users:
When working in relative mode, you can also use more complex commands. For example, this command adds write permission to a group and removes reads for others:
When using chmod -R o + rx / data, you set the execution permission for all directories, as well as for files in the / data directory. To set permission to execute only for directories, not files, use chmod -R o + rX / data .
Upper case X ensures that the files do not get permission to execute if the file has not already set permission to execute for some objects. This makes X a smarter way to work with execute permissions; this will avoid installing this permission on files where it is not required.
In addition to the basic permissions that you just read about, Linux also has a set of advanced permissions. These are not the default permissions that you set, but sometimes they provide a useful addition. In this section, you will learn what they are and how to configure them.
There are three advanced permissions. The first of these is permission to set a user identifier (SUID). In some special cases, you can apply this permission to executable files. By default, the user running the executable executes the file with its own permissions.
For ordinary users, this usually means that the use of the program is limited. However, in some cases, the user requires special permissions only to perform a specific task.
Consider, for example, a situation where the user needs to change the password. To do this, the user must write his new password to the / etc / shadow file. However, this file is not writable by non-root users:
Resolution SUID offers a solution to this problem. In the / usr / bin / passwd utility, this permission is used by default. This means that when the password is changed, the user temporarily gets root privileges, which allows him to write to the / etc / shadow file. You can see the SUID resolution with ls -l as s in the position where you usually expect to see x for user permissions:
SUID permissions may look useful (and in some cases they are), but at the same time they are potentially dangerous. If applied incorrectly, you may accidentally give root access permissions. Therefore, I recommend using it only with extreme caution.
Most administrators will never have to use it; you will see it only in some files where the operating system should set it by default.
The second special permission is the group identifier (SGID). This resolution has two effects. When applied to an executable file, it gives the user who is executing the file the permissions of the group owner of this file. Thus, the SGID can do more or less the same as the SUID. However, SGID is practically not used for this purpose.
As with SUID permission, SGID is applied to some system files as the default setting.
When applied to a directory, SGID can be useful because you can use it to set the default group owner for the files and subdirectories created in this directory. By default, when a user creates a file, his effective primary group is set as the group owner for this file.
This is not always very useful, especially because Red Hat / CentOS users have 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.
Imagine a situation where linda and lori users work in accounting and are members of the account group. By default, these users are members of the private group of which they are the only member. However, both users are members of the account group, but also as a parameter of the secondary group.
The default situation is that when any of these users creates a file, the main 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 make sure that the SGID permission is applied to this directory and that group accounting is set as the group owner for this directory, all files created in this directory and in all its subdirectories , also get account groups as the default group owner.
For this reason, SGID permission is a very useful permission to install on shared group directories.
The SGID permission is shown in the output ls -ld as s at the position where you usually find permission to execute the group:
The third of the special permissions is sticky bit. This permission is useful for protecting files from accidental deletion in an environment where multiple users have write permissions to the same directory. If a sticky bit is used, the user can delete a file only if he is the user who owns the file or directory in which the file is located. For this reason, it is used as the default permission for the / tmp directory and may also be useful for shared group directories.
Without sticky bit, if a user can create files in a directory, he can also delete files from this directory. In a public group environment, this can be annoying. Imagine users linda and lori, who both have write permissions to the / data / account directory and receive these permissions through membership in the account group. Therefore, linda can delete files created by lori, and vice versa.
When you use sticky bit, the user can delete files only if one of the following conditions is true:
When using ls -ld , you can see sticky bit as t at the position where you usually see execution permission for others:
To apply SUID, SGID and sticky bit, you can also use chmod . SUID has a numerical value of 4, SGID has a numerical value of 2, and sticky bit has a numerical value of 1.
If you want to apply these permissions, you need to add a four-digit argument to chmod , the first digit of which refers to special permissions. The following line, for example, will add SGID permission to the directory and set rwx for the user and rx for the group and others:
This is pretty 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 do not.) Therefore, I recommend working in relative mode if you need to apply any of the special permissions:
The table summarizes everything that is important to know about managing special permissions.
In this example, you use special permissions to make it easier for team members to share files in a shared group directory. You assign the ID-bit of the set group identifier, as well as sticky bit, and you see that after they are installed, functions are added that facilitate the joint work of group members.
Even if the extended rights discussed above add useful functionality to how Linux works with permissions, this does not allow you to grant permissions to more than one user or one group in a single file.
Access control lists offer this feature. In addition, they allow administrators to set default permissions in a complex way in which the set permissions can vary in different directories.
Although the ACL subsystem adds great functionality to your server, it has one drawback: not all utilities support it. Therefore, you may lose ACL settings when copying or moving files, and backup software may not back up ACL settings.
The tar utility does not support ACLs. To ensure that the ACL settings are not lost when backing up, use star instead of tar. star works with the same parameters as tar; it just adds support for ACL settings.
You can also back up the ACL using getfacl , which can be restored using the setfacl command. To create a backup, usegetfacl -R / directory> file.acls . To restore the settings from the backup file, use setfacl --restore = file.acl .
Lack of support with some tools should not be a problem. ACLs are often applied to directories as a structural measure, rather than to individual files.
Therefore, there will not be many, but only a few, applied in smart places of the file system. Therefore, restoring the original ACLs that you worked with is relatively easy, even if your backup software does not support them.
Before you start working with ACLs, you may need to prepare a file system to support ACLs. Because file system metadata needs to be expanded, there is not always default support for ACLs in the file system. If you receive the message “operation not supported” when configuring ACLs for the file system, your file system may not have ACL support.
To fix this, you need to add the acl mount option in the / etc / fstab file so that the file system is mounted with ACL support by default.
To set the ACL, you need the setfacl command . To see the current ACL settings, you need getfacl . The ls -l command does not show any existing ACLs; it simply shows + after the permission list, which indicates that ACLs apply to the file as well.
Before configuring ACLs, it is always useful to show the current ACL settings using getfacl . Below with an example, you can see the current permissions, as shown with ls -ld , as well as shown with getfacl . If you look carefully enough, you will see that the information shown is exactly the same.
As a result of the getfacl command , you can see below 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. The command for this is setfacl -mg: sales: rx / dir . In this command, -m indicates that the current ACL settings must be changed. After that, g: sales: rx tells the team to set the ACL to read and execute ( rx ) for group ( g ) sales. Below you can see how the command looks, as well as the output of the getfacl command after changing the current ACL settings.
Now that you understand how to set up a group ACL, it is easy to understand the ACL for users and other users. For example, the setfacl -mu: linda: rwx / data command gives permissions to the linda user in the / data directory without making it the owner or changing the destination of the current owner.
The setfacl command has many features and options. One option is especially important, the -R option . If used, this option configures the ACL for all files and subdirectories that currently exist in the directory where you install the ACL. It is recommended that you always use this option when modifying ACLs for existing directories.
One advantage of using ACLs is that you can give permissions to multiple users or groups in a directory. Another advantage is that you can enable inheritance by working with the default ACL.
By setting the default ACL, you define the permissions that will be set for all new items created in the directory. Keep in mind that the default ACL does not change permissions for existing files and subdirectories. To change them, you need to add a regular ACL!
This is important to know. If you want to use the ACL to configure access for multiple users or groups to the same directory, you must set the ACL twice. First use setfacl -R -m to change the ACL for the current files. Then usesetfacl -md: to take care of all the new elements that will also be created.
To set the default ACL, you just need to add the d option after the -m option (order matters!). So use setfacl -md: g: sales: rx / data if you want the sales group to have read and execute access to anything that will ever be 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 permissions for others using chmod . However, what you cannot do with chmod, this indicates the rights that should be granted to other users for each new file that will ever be created. If you want others to not get any permissions for anything created in / data, for example, use setfacl -md: o :: - / data .
ACLs and regular permissions are not always well integrated. Problems can occur if you apply the default ACL to a directory, after which items have been added to this 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, first set the normal permissions, then set the default ACL (and after that try not to change them again).
In this example, you will continue to work with the directories / data / account and / data / sales that you created earlier. In the previous examples, you guaranteed that the sales group has permissions for / data / sales, and the account group has permissions for / data / account.
First, make sure the account group gets read permissions in the / data / account directory, and the sales group gets read permissions in the / data / account directory.
You then set the default ACLs to make sure that all new files have permissions set correctly for all new items.
Above, you learned how to work with ACLs by default. If you are not using an ACL, there is a shell parameter that defines the default rights that you will receive: umask (backward mask). In this section, you will learn how to change the default permissions using umask .
You probably noticed that when you create a new file, some default permissions are set. These permissions are determined by the umask setting . This shell option applies to all users at logon. The umask parameter uses a numeric value that is subtracted from the maximum permissions that can be automatically set for the file; the maximum setting for files is 666, and for directories - 777.
However, some exceptions apply to this rule. You can find a complete overview of umask settings in the table below.
Of the digits used in umask , as in the case of numeric arguments for the chmod command , the first digit refers to user permissions, the second digit refers to group permissions, and the last refers to the default permissions set for others. The default umask value of 022 gives 644 for all new files and 755 for all new directories created on your server.
A complete overview of all umask numeric values and their results in the table below.
An easy way to see how the umask parameter works is as follows: start with the default permissions for the file set to 666, and subtract umask to get valid 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 install umask for all users, you must ensure that the umask parameter is taken into account when running shell environment files, as specified in / etc / profile. The correct approach is to create a shell script named umask.sh in the /etc/profile.d directory and specify the umask that you want to use in this shell script. If umask is changed in this file, it is applied to all users after entering the server.
An alternative to configuring umask through / etc / profile and related files, where it is applied to all users on the system, is to change the umask settings in a file named .profile, which is created in each user's home directory.
The settings applied in this file are applied only to an individual user; therefore, this is a good method if you need more detail. I personally like this feature to change the default umask value for the root user to 027, while regular users work with the default umask 022.
This is the final section on Linux rights.
When working with permissions, there is always a relationship between a user or group object and the permissions that these user or group objects have for the file or directory. An alternative method of protecting files on a Linux server is working with attributes.
Attributes do their job regardless of the user who accesses the file.
As with ACLs, file attributes may need to include the mount option .
This is the user_xattr option . If you get a “operation not supported” message when working with advanced user attributes, be sure to set the mount parameter in the / etc / fstab file.
Many attributes are documented. Some attributes are available but not yet implemented. Do not use them; they won’t bring you anything.
The following are the most useful attributes you can apply:
A This attribute ensures that the access time to the file of the file does not change.
Usually every time a file is opened, the file access time should be written to the file’s metadata. This adversely affects performance; therefore, for files that are regularly accessed, attribute A can be used to disable this feature.
a This attribute allows you to add but not delete a file.
cIf you use a file system that supports volume-level compression, this file attribute ensures that the file will be compressed the first time the compression engine is enabled.
D This attribute ensures that changes to files are written to disk immediately, and not cached in the first place. This is a useful attribute in important database files, making sure that they are not 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.
IThis attribute enables indexing for the directory in which it is included. This provides faster file access for primitive file systems such as Ext3, which do not use the B-tree database for quick file access.
i This attribute makes the file unchanged. Therefore, you cannot make changes to the file, which is useful for files that need additional protection.
j This attribute ensures that in the ext3 file system, the file is first written to the log and then to the data blocks on the hard disk.
s Overwrite the blocks in which the file was saved for 0 s after deleting the file. This ensures that file recovery is not possible after it has been deleted.
uThis attribute stores deletion information. This allows you to develop a utility that works with this information to save deleted files.
If you want to apply attributes, you can use the chattr command . For example, use chattr + s somefile to apply attributes to somefile. Need to remove an attribute? Then use chattr -s somefile and it will be deleted. To get an overview of all the attributes that are currently used, use the lsattr command .
In this article, you learned how to work with permissions. You read about three basic permissions, advanced permissions, and how to apply ACLs to the file system. You also learned how to use the umask parameter to apply default permissions. At the end of this article, you learned how to use user-advanced 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.
From myself: I hope the article will be useful not only for beginners, but also will help more experienced administrators organize their knowledge.
So let's go.
To access files on Linux, permissions are used. These permissions are assigned to three objects: a file, a group, and another object (that is, everyone else). In this article, you will learn how to apply permissions.
The article begins with a review of the basic concepts, after which special permissions and access control lists (ACLs) are discussed. At the end of this article, we will look at setting default permissions through umask, as well as managing advanced user attributes.
File ownership management
Before discussing permissions, you should be aware of the role of the owner of the file and directory. Owning files and directories is vital to working 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.
Display owner of a file or directory
On Linux, each file and each directory has two owners: a user and a group.
These owners are set when the file or directory is created. The user who creates the file becomes the owner of this file, and the primary group, which includes the same user, also becomes the owner of this file. To determine whether you as a user have access rights to a file or directory, the shell checks its ownership.
This happens in the following order:
- The shell checks to see if you own the file that you want to access. If you are this owner, you get permissions and the shell stops checking.
- If you do not own the file, the shell will check if you are a member of a group that has permissions on this file. If you are a member of this group, you gain access to the file with the permissions that are set for the group, and the shell will stop checking.
- If you are neither the user nor the owner of the group, you get the rights of other users (Other).
To see the current owner assignments, you can use the ls -l command . This command shows the user and owner 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
Using the ls command, you can display the owner of the files in this directory. Sometimes it may be useful to get a list of all the files in the system in which the user or group is specified as the owner. You can use find for this . The find -user argument can be used for this purpose. For example, the following command shows all files that have the linda user specified as the owner:
find / -user linda
You can also use find to search for files in which a particular group owns them.
For example, the following command searches for all files belonging to the users group:
find / -group users
Change of ownership
To apply permissions, the first thing to consider is ownership. There is a chown command for this. The syntax of this command is easy to understand:
chown
For example, the following command changes the owner of the / home / account directory to user linda:
chown linda /home/account
The chown command has several options, one of which is especially useful: -R . You can guess what it does, because this option is also available for many other teams. 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 the owner for the / home directory and everything below it to lisa:
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
Run:
[root@localhost ~]# chown -R lisa /home/account [root@localhost ~]#
Now 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
Group owner change
There are two ways to change group ownership. You can do this using chown , but there is a special command called chgrp that does the job. If you want to use the chown command , use . or : before the name of the group.
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 lisa to own myfile1.
- chown lisa.sales myfile sets the lisa user to the owner of the myfile file, and also sets the sales group to the owner of the same file.
- chown lisa: sales myfile is the same as the previous command.
- chown .sales myfile sets the sales group to be the owner of the myfile file without changing the owner of the user.
- chown: sales myfile is the same as the previous command.
You can use the chgrp command to change the group owner. Consider the following example, where you can use chgrp to set the sales group as the owner of the account directory:
chgrp .sales /home/account
As with chown , you can use the -R option with chgrp , as well as recursively change the group owner.
Understanding the default owner
You may notice that when the user creates the file, default ownership is applied.
The user who creates the file automatically becomes the owner of this file, and the main group of this user automatically becomes the owner of this file. This is usually a group that is specified in the / etc / passwd file as the user's main group. However, if the user is a member of several groups, he can change the effective core group.
To show the current effective primary group, the user can use the groups command:
[root@server1 ~]# groups lisa lisa : lisa account sales
If the current user linda wants to change the effective primary group, he will use the newgrp command, followed by the name of the group that he wants to set as the new effective primary group. After using the newgrp command, the primary group will be active until the user issues the exit command or logs out.
The following shows how lisa uses this command so that the sales group becomes 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 current main group, all new files created by the user will receive this group as the owner group. To return to the initial setting of the primary group, use exit .
To be able to use the newgrp command, the user must be a member of the group that he wants to use as primary. In addition, the group password can be used for the group using the gpasswd command. If the user uses the newgrp command but is not a member of the target group, the shell requests the group password. After you enter the correct group password, a new effective primary group will be set.
Fundamental Rights Management
The Linux permission system was invented in the 1970s. Since computing needs were limited in those years, the basic permission system was rather 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 Rights
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, read permission gives you the right to open the file for reading. Therefore, you can read its contents, but this means that your computer can open the file to do something with it.
A program file that needs access to a library should, for example, have read access to that library. It follows that read permission is the most basic permission you need to work with files.
For a directory, reading allows you to display the contents of that directory. You should know that this permission does not allow you to read files in a directory. Linux permissions do not know inheritance, and the only way to read a file is to use read permissions for that file.
As you can probably guess, the write permission, if applied to the file, allows you to write to the file. In other words, it allows you to modify the contents of existing files. However, it does not allow creating or deleting new files or changing 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.
Execution 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 to the directory can apply permission to execute.
The following summarizes the use of basic permissions:
Using chmod
To manage rights, use the chmod command . When using chmod, you can set permissions for the user (user), group (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 the basic permissions.
When setting permissions, calculate the value you need. If you want to set read, write and execute for the user, read and execute for the group, and read and execute for others in the / somefile, then you use the following chmod command :
chmod 755 /somefile
When you use chmod in this way, all current permissions are replaced by the permissions you set.
If you want to change permissions relative to current permissions, you can use chmod in relative mode. When using chmod in relative mode, you are working with three indicators to indicate what you want to do:
- First you indicate for whom you want to change permissions. To do this, you can choose between user ( u ), group ( g ) and others ( o ).
- Then you use the operator to add or remove permissions from the current mode, or set them completely.
- In the end, you use r , w, and x to indicate which permissions you want to set.
When changing permissions in relative mode, you can skip the “to” part to add or remove permission for all objects. For example, this command adds execution permission for all users:
chmod +x somefile
When working in relative mode, you can also use more complex commands. For example, this command adds write permission to a group and removes reads for others:
chmod g+w,or somefile
When using chmod -R o + rx / data, you set the execution permission for all directories, as well as for files in the / data directory. To set permission to execute only for directories, not files, use chmod -R o + rX / data .
Upper case X ensures that the files do not get permission to execute if the file has not already set permission to execute for some objects. This makes X a smarter way to work with execute permissions; this will avoid installing this permission on files where it is not required.
Extended Rights
In addition to the basic permissions that you just read about, Linux also has a set of advanced permissions. These are not the default permissions that you set, but sometimes they provide a useful addition. In this section, you will learn what they are and how to configure them.
Understanding extended SUID, GUID and sticky bit rights
There are three advanced permissions. The first of these is permission to set a user identifier (SUID). In some special cases, you can apply this permission to executable files. By default, the user running the executable executes the file with its own permissions.
For ordinary users, this usually means that the use of the program is limited. However, in some cases, the user requires special permissions only to perform a specific task.
Consider, for example, a situation where the user needs to change the password. To do this, the user must write his 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
Resolution SUID offers a solution to this problem. In the / usr / bin / passwd utility, this permission is used by default. This means that when the password is changed, the user temporarily gets root privileges, which allows him to write to the / etc / shadow file. You can see the SUID resolution with ls -l as s in the position where you usually expect to see x for user permissions:
[root@hnl ~]# ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 32680 Jan 28 2010 /usr/bin/passwd
SUID permissions may look useful (and in some cases they are), but at the same time they are potentially dangerous. If applied incorrectly, you may accidentally give root access permissions. Therefore, I recommend using it only with extreme caution.
Most administrators will never have to use it; you will see it only in some files where the operating system should set it by default.
The second special permission is the group identifier (SGID). This resolution has two effects. When applied to an executable file, it gives the user who is executing the file the permissions of the group owner of this file. Thus, the SGID can do more or less the same as the SUID. However, SGID is practically not used for this purpose.
As with SUID permission, SGID is applied to some system files as the default setting.
When applied to a directory, SGID can be useful because you can use it to set the default group owner for the files and subdirectories created in this directory. By default, when a user creates a file, his effective primary group is set as the group owner for this file.
This is not always very useful, especially because Red Hat / CentOS users have 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.
Imagine a situation where linda and lori users work in accounting and are members of the account group. By default, these users are members of the private group of which they are the only member. However, both users are members of the account group, but also as a parameter of the secondary group.
The default situation is that when any of these users creates a file, the main 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 make sure that the SGID permission is applied to this directory and that group accounting is set as the group owner for this directory, all files created in this directory and in all its subdirectories , also get account groups as the default group owner.
For this reason, SGID permission is a very useful permission to install on shared group directories.
The SGID permission is shown in the output ls -ld as s at the position where you usually find permission to execute the 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 sticky bit. This permission is useful for protecting files from accidental deletion in an environment where multiple users have write permissions to the same directory. If a sticky bit is used, the user can delete a file only if he is the user who owns the file or directory in which the file is located. For this reason, it is used as the default permission for the / tmp directory and may also be useful for shared group directories.
Without sticky bit, if a user can create files in a directory, he can also delete files from this directory. In a public group environment, this can be annoying. Imagine users linda and lori, who both have write permissions to the / data / account directory and receive these permissions through membership in the account group. Therefore, linda can delete files created by lori, and vice versa.
When you use sticky bit, the user can delete files only if one of the following conditions is true:
- The user is the owner of the file;
- The user is the owner of the directory in which the file is located.
When using ls -ld , you can see sticky bit as t at the position where you usually see execution permission for others:
[root@hnl data]# ls -ld account/ drwxr-sr-t. 2 root account 4096 Apr 30 21:28 account/
Enhanced Rights
To apply SUID, SGID and sticky bit, you can also use chmod . SUID has a numerical value of 4, SGID has a numerical value of 2, and sticky bit has a numerical value of 1.
If you want to apply these permissions, you need to add a four-digit argument to chmod , the first digit of which refers to special permissions. The following line, for example, will add SGID permission to the directory and set rwx for the user and rx for the group and others:
chmod 2755 /somedir
This is pretty 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 do not.) Therefore, I recommend working 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 and then the name of the file or directory for which you want to set permissions.
The table summarizes everything that is important to know about managing special permissions.
Example of working with special rights
In this example, you use special permissions to make it easier for team members to share files in a shared group directory. You assign the ID-bit of the set group identifier, as well as sticky bit, and you see that after they are installed, functions are added that facilitate the joint work of group members.
- Open the terminal where you are a linda user. You can create a user using the command useradd linda , add the password passwd linda .
- Create a directory / data and a subdirectory / data / sales in the root with the command mkdir -p / data / sales . Run cd / data / sales to go to the sales directory. Run touch linda1 and touch linda2 to create two empty files owned by linda.
- Run su - lisa to switch the current user to user lisa, who is also a member of the sales group.
- Run cd / data / sales and from this directory, execute ls -l . You will see two files that were created by linda and belong to the linda group. Run rm -f linda * . This will delete both files.
- Run touch lisa1 and touch lisa2 to create two files that belong to user lisa.
- Run su - to elevate your privileges to root level.
- Run chmod g + s, o + t / data / sales to set the group identifier bit (GUID) as well as the sticky bit in the shared group directory.
- Run su - linda . Then do touch linda3 and touch linda4 . Now you should see that the two files you created belong to the sales group, which is the owner of the / data / sales directory group.
- Run rm -rf lisa * . Sticky bit prevents these files from being deleted on behalf of linda as you do not own these files. Please note that if linda is the owner of the / data / sales directory, he can delete these files anyway!
Managing ACLs (setfacl, getfacl) on Linux
Even if the extended rights discussed above add useful functionality to how Linux works with permissions, this does not allow you to grant permissions to more than one user or one group in a single file.
Access control lists offer this feature. In addition, they allow administrators to set default permissions in a complex way in which the set permissions can vary in different directories.
Understanding ACLs
Although the ACL subsystem adds great functionality to your server, it has one drawback: not all utilities support it. Therefore, you may lose ACL settings when copying or moving files, and backup software may not back up ACL settings.
The tar utility does not support ACLs. To ensure that the ACL settings are not lost when backing up, use star instead of tar. star works with the same parameters as tar; it just adds support for ACL settings.
You can also back up the ACL using getfacl , which can be restored using the setfacl command. To create a backup, usegetfacl -R / directory> file.acls . To restore the settings from the backup file, use setfacl --restore = file.acl .
Lack of support with some tools should not be a problem. ACLs are often applied to directories as a structural measure, rather than to individual files.
Therefore, there will not be many, but only a few, applied in smart places of the file system. Therefore, restoring the original ACLs that you worked with is relatively easy, even if your backup software does not support them.
Preparing the file system for an ACL
Before you start working with ACLs, you may need to prepare a file system to support ACLs. Because file system metadata needs to be expanded, there is not always default support for ACLs in the file system. If you receive the message “operation not supported” when configuring ACLs for the file system, your file system may not have ACL support.
To fix this, you need to add the acl mount option in the / etc / fstab file so that the file system is mounted with ACL support by default.
Change and view ACL settings with setfacl and getfacl
To set the ACL, you need the setfacl command . To see the current ACL settings, you need getfacl . The ls -l command does not show any existing ACLs; it simply shows + after the permission list, which indicates that ACLs apply to the file as well.
Before configuring ACLs, it is always useful to show the current ACL settings using getfacl . Below with an example, you can see the current permissions, as shown with ls -ld , as well as shown with getfacl . If you look carefully 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::rx other::rx
As a result of the getfacl command , you can see below 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. The command for this is setfacl -mg: sales: rx / dir . In this command, -m indicates that the current ACL settings must be changed. After that, g: sales: rx tells the team to set the ACL to read and execute ( rx ) for group ( g ) sales. Below you can see how the command looks, as well as the output of the getfacl command after changing the current ACL settings.
[root@server1 /]# setfacl -mg:sales:rx /dir [root@server1 /]# getfacl /dir getfacl: Removing leading '/' from absolute path names # file: dir # owner: root # group: root user::rwx group::rx group:sales:rx mask::rx other::rx
Now that you understand how to set up a group ACL, it is easy to understand the ACL for users and other users. For example, the setfacl -mu: linda: rwx / data command gives permissions to the linda user in the / data directory without making it the owner or changing the destination of the current owner.
The setfacl command has many features and options. One option is especially important, the -R option . If used, this option configures the ACL for all files and subdirectories that currently exist in the directory where you install the ACL. It is recommended that you always use this option when modifying ACLs for existing directories.
Work with default ACLs
One advantage of using ACLs is that you can give permissions to multiple users or groups in a directory. Another advantage is that you can enable inheritance by working with the default ACL.
By setting the default ACL, you define the permissions that will be set for all new items created in the directory. Keep in mind that the default ACL does not change permissions for existing files and subdirectories. To change them, you need to add a regular ACL!
This is important to know. If you want to use the ACL to configure access for multiple users or groups to the same directory, you must set the ACL twice. First use setfacl -R -m to change the ACL for the current files. Then usesetfacl -md: to take care of all the new elements that will also be created.
To set the default ACL, you just need to add the d option after the -m option (order matters!). So use setfacl -md: g: sales: rx / data if you want the sales group to have read and execute access to anything that will ever be 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 permissions for others using chmod . However, what you cannot do with chmod, this indicates the rights that should be granted to other users for each new file that will ever be created. If you want others to not get any permissions for anything created in / data, for example, use setfacl -md: o :: - / data .
ACLs and regular permissions are not always well integrated. Problems can occur if you apply the default ACL to a directory, after which items have been added to this 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, first set the normal permissions, then set the default ACL (and after that try not to change them again).
Advanced Rights Management Example Using ACLs
In this example, you will continue to work with the directories / data / account and / data / sales that you created earlier. In the previous examples, you guaranteed that the sales group has permissions for / data / sales, and the account group has permissions for / data / account.
First, make sure the account group gets read permissions in the / data / account directory, and the sales group gets read permissions in the / data / account directory.
You then set the default ACLs to make sure that all new files have permissions set correctly for all new items.
- Open a terminal.
- Run setfacl -mg: account: rx / data / sales and setfacl -mg: sales: rx / data / account .
- getfacl , , , .
- setfacl -md:g:account:rwx,g:sales:rx /data/sales , ACL sales.
- ACL /data/account, setfacl -md:g:sales:rwx,g:account:rx /data/account .
- , ACL , /data/sales. touch /data/sales/newfile getfacl /data/sales/newfile .
umask
Above, you learned how to work with ACLs by default. If you are not using an ACL, there is a shell parameter that defines the default rights that you will receive: umask (backward mask). In this section, you will learn how to change the default permissions using umask .
You probably noticed that when you create a new file, some default permissions are set. These permissions are determined by the umask setting . This shell option applies to all users at logon. The umask parameter uses a numeric value that is subtracted from the maximum permissions that can be automatically set for the file; the maximum setting for files is 666, and for directories - 777.
However, some exceptions apply to this rule. You can find a complete overview of umask settings in the table below.
Of the digits used in umask , as in the case of numeric arguments for the chmod command , the first digit refers to user permissions, the second digit refers to group permissions, and the last refers to the default permissions set for others. The default umask value of 022 gives 644 for all new files and 755 for all new directories created on your server.
A complete overview of all umask numeric values and their results in the table below.
An easy way to see how the umask parameter works is as follows: start with the default permissions for the file set to 666, and subtract umask to get valid 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 install umask for all users, you must ensure that the umask parameter is taken into account when running shell environment files, as specified in / etc / profile. The correct approach is to create a shell script named umask.sh in the /etc/profile.d directory and specify the umask that you want to use in this shell script. If umask is changed in this file, it is applied to all users after entering the server.
An alternative to configuring umask through / etc / profile and related files, where it is applied to all users on the system, is to change the umask settings in a file named .profile, which is created in each user's home directory.
The settings applied in this file are applied only to an individual user; therefore, this is a good method if you need more detail. I personally like this feature to change the default umask value for the root user to 027, while regular users work with the default umask 022.
Working with advanced user attributes
This is the final section on Linux rights.
When working with permissions, there is always a relationship between a user or group object and the permissions that these user or group objects have for the file or directory. An alternative method of protecting files on a Linux server is working with attributes.
Attributes do their job regardless of the user who accesses the file.
As with ACLs, file attributes may need to include the mount option .
This is the user_xattr option . If you get a “operation not supported” message when working with advanced user attributes, be sure to set the mount parameter in the / etc / fstab file.
Many attributes are documented. Some attributes are available but not yet implemented. Do not use them; they won’t bring you anything.
The following are the most useful attributes you can apply:
A This attribute ensures that the access time to the file of the file does not change.
Usually every time a file is opened, the file access time should be written to the file’s metadata. This adversely affects performance; therefore, for files that are regularly accessed, attribute A can be used to disable this feature.
a This attribute allows you to add but not delete a file.
cIf you use a file system that supports volume-level compression, this file attribute ensures that the file will be compressed the first time the compression engine is enabled.
D This attribute ensures that changes to files are written to disk immediately, and not cached in the first place. This is a useful attribute in important database files, making sure that they are not 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.
IThis attribute enables indexing for the directory in which it is included. This provides faster file access for primitive file systems such as Ext3, which do not use the B-tree database for quick file access.
i This attribute makes the file unchanged. Therefore, you cannot make changes to the file, which is useful for files that need additional protection.
j This attribute ensures that in the ext3 file system, the file is first written to the log and then to the data blocks on the hard disk.
s Overwrite the blocks in which the file was saved for 0 s after deleting the file. This ensures that file recovery is not possible after it has been deleted.
uThis attribute stores deletion information. This allows you to develop a utility that works with this information to save deleted files.
If you want to apply attributes, you can use the chattr command . For example, use chattr + s somefile to apply attributes to somefile. Need to remove an attribute? Then use chattr -s somefile and it will be deleted. To get an overview of all the attributes that are currently used, use the lsattr command .
Summary
In this article, you learned how to work with permissions. You read about three basic permissions, advanced permissions, and how to apply ACLs to the file system. You also learned how to use the umask parameter to apply default permissions. At the end of this article, you learned how to use user-advanced 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.
. .
« - .» « - .», .
berez .
:
, , , .
:
, , , . , , , .
CryptoPirate
All Articles