Introduction to ACL (Access Control List) in CentOS

Introduction to ACL (Access Control List) in CentOS

We know that in a Linux operating system, the traditional permission management is divided into three types of permissions (readable, writable, and executable) in combination with three identities (owner, owner, and other persons ), it also works with three special permissions (SUID, SGID, and SBIT) to implement system security protection. However, with the development and expansion of business and needs, the only mode can no longer meet the permission control requirements in the current complex environment.

For example, there is A/data directory. Now, the members in group A need to be writable, the members in Group B only read, and the Members in group C can read and write. What should we do?

The preceding requirements cannot be achieved only by relying on the existing traditional permission management model. To solve this type of problem, Linux has developed a new file system permission management method called the Access Control list ACL (Access Control Lists ). By using ACL, You can perfectly solve the above Type of requirements.

So what is the access control list?

What is ACL?

ACL is the abbreviation of Access Control List. It aims to provide more detailed local permission settings in addition to the traditional three identities and three permissions. In the official manual, it mainly controls permissions for users, user groups, and masks.
In simple terms, ACL can be used to control the permissions of a single user or a single user group.
In windows, without this ACL, ACL is an additional support item for Unix-like operating system permissions. Therefore, you must have file system support to use the ACL. It mainly includes ReiserFS, EXT2/EXT3/ext4, JFS, XFS and other file systems.

Does the file system support ACL?

Note that because ACL depends on the file system, not every file system supports ACL. For example, in the NTFS file system of win platform, the FAT32 file system does not support ACL. On the Linux platform, common ACL-supported files love your system, such as EXT2/EXT3/ext4, JFS, and XFS.

So, how can we check whether your system supports ACL?

You can perform the following operations:

[Root @ lh ~] # Tune2fs-l/dev/vda1 | grepoptionsdefamounmountoptions: user_xattracl [root @ lh ~] # Dumpe2fs/dev/vda1 | grepoptionsdumpe2fs1.41.12 (17-May-2010) Defaultmountoptions: user_xattracl

Select either of the above two commands!

If the output information contains the acl identifier in the default mount option, it indicates that your file system supports this identifier.

Assume that your file system does not support or support this acl identity, but does not display it. What should I do? In this case, we can use tune2fs to add it or mount it.

[Root @ lh ~] # Tune2fs-oacl/dev/vda1tune2fs1.41.12 (17-May-2010)

Detailed description of ACL commands

This section describes what ACL is and how to enable the file system to support ACL.

ACL-related operations include getface, setfacl, and chacl. getfacl and setfacl are commonly used.

Getfacl is used to view the ACL settings of a file/directory. setfacl is used to set the ACL content of a file/directory. chacl is used to view and change the ACL content of a file/directory. Because setfacl is commonly used, chacl is never used, this article does not introduce

Generally, getfacl is directly followed by the path of the file or directory you want to view. The procedure is as follows:

[Root @ lh ~] # Getfacl/tmpgetfacl: Removingleading '/'fromabsolutepathnames # file: tmp # owner: root # group: root # flags: -- tuser: rwxgroup: rwxother :: rwx [root @ lh ~] # Getfacl/etc/passwdgetfacl: Removingleading '/'fromabsolutepathnames # file: etc/passwd # owner: root # group: rootuser: rw-group: r -- other: r --

Setfacl is the most commonly used, and is used for basic ACL operations. Therefore, it has many options. First, use the setfacl Syntax:

Setfacl [-bkRd] [{-m |-x} acl parameter] File/directory path options:-B: delete all acl parameters-k: delete preset acl parameters-R: recursively set the following acl parameters-d: Set the preset acl parameters (only valid for directories, the default ACL value is also used for files created in this directory.-m: sets (modifies) the following acl parameters:-x: deletes the specified acl parameters.

The ACL parameter consists of three parts. The structure is as follows:

Three identities: corresponding identity names: Three permissions [u | g | o]: [user name | user group name]: [rwx]

Instance exercises

Let's take a look at several instances to understand the learning ACL operation:

Now, in the/mnt directory, There are files test and directory dir. Their permissions are 600, and both the owner and the owner are root.

[Root @ lhmnt] # touchtest [root @ lhmnt] # mkdirdir [root @ lhmnt] # chmod600test [root @ lhmnt] # chmod600dir [root @ lhmnt] # lltotal4drw -------. 2rootroot4096Jul417: 56dir-rw -------. 1rootroot0Jul417: 56 test

The following requirements must be met:

1. Add acl permissions for file test so that sunsky users can read and write

[Root @ lhmnt] # setfacl-mu: sunsky: rwtest [root @ lhmnt] # getfacltest # file: test # owner: root # group: rootuser: rw-user: sunsky: rw-group: --- mask: rw-other: --- [root @ lhmnt] # su-sunsky # Switch to the sunsky user and test WellcometoLinuxWorld [sunsky @ lh ~] $ Echo1>/mnt/test # It is obvious that data can be written [sunsky @ lh ~] $ Cat/mnt/test1

2. Add the acl permission for the file test so that all users in the sun group can read the file.

[Root @ lhmnt] # setfacl-mg: sun: rtest [root @ lhmnt] # getfacltest # file: test # owner: root # group: rootuser: rw-user: sunsky: rw-group: --- group: sun: r -- mask: rw-other: --- [root @ lhmnt] # su-sunWellcometoLinuxWorld [sun @ lh ~] $ Cat/mnt/test # It is obvious that you can view the content of the test file 1 [sun @ lh ~] $ Echo2>/mnt/test # We cannot change-bash:/mnt/test: Permissiondenied because we have not changed the permissions for sun members.

3. Add acl permissions for the Directory dir so that all users in the sun group can read, write, and execute the Directory

[Root @ lhmnt] # setfacl-mg: sun: rwdir [root @ lhmnt] # getfacldir # file: dir # owner: root # group: rootuser: rw-group :: --- group: sun: rwxmask: rwxother: --- [root @ lhmnt] # su-sun # Switch to the sun user and test [sun @ lh ~] $ Echo "date">/mnt/dir/date. sh [sun @ lh ~] $ Bash/mnt/dir/date. shFriJul418: 01: 48CST2014

4. Delete the acl permission of the sun group on the file test.

[Root @ lhmnt] # setfacl-xg: suntest [root @ lhmnt] # getfacltest # file: test # owner: root # group: rootuser: rw-user: sunsky: rw-group: --- mask: rw-other ::---

5. Delete All ACL permissions for the Directory dir

[Root @ lhmnt] # setfacl-bdir [root @ lhmnt] # getfacldir # file: dir # owner: root # group: rootuser: rw-group: --- other ::---

6. Add the default ACL permission to the directory dir so that all newly created files or directories under the dir directory can be read and writable by sunsky users by default.

[Root @ lhmnt] # setfacl-md: u: sunsky: rwxdir [root @ lhmnt] # getfacldir # file: dir # owner: root # group: rootuser: rw-group:: --- other: --- default: user: rw-default: user: sunsky: rwxdefault: group: --- default: mask: rwxdefault: other :: --- [root @ lhmnt] # touch/mnt/dir/sunsky [root @ lhmnt] # getfacl/mnt/dir/sunskygetfacl: Removingleading '/'fromabsolutepathnames # file: mnt/dir/sunsky # owner: root # group: rootuser: rw-user: sunsky: rwx # valid tive: rw-group: --- mask: rw-other ::---

In the sixth question, we found that there is a # additional tive: rw-after user: sunsky: rwx. Why? Switch to the sunsky user to see if it has the permission to execute the file!

[Root @ lhmnt] # su-sunskyWellcometoLinuxWorld [sunsky @ lh ~] $ Bash/mnt/dir/sunskybash:/mnt/dir/sunsky: Permissiondenied

Obviously, although setfacl is used to grant sunsky the permission to read, write, and execute new files in the dir directory by default, it still has no execution permission. Why?

We found that there is more output # Lead tive: rw-. Why does it come out?

The valid aspect is rw, which is affected by the mask in our output. But we found that we didn't set mask. Why does it change to rw by default. Here I will introduce mask!

Mask is used to restrict the permissions of all users or groups except the owner and others. mask permissions are the highest possible permissions for these users.
If the configured user permission conflicts with the mask permission, the user's permission is
# Valid Permission
Once an object is configured with an ACL, the permissions of the original file group will be changed to the MASK permission, rather than the original group permission. If the permissions of the file owner are empty, after you set the mask permission, the permissions of your owner are changed to the permissions of its mask.

Next, let's continue with the sixth lab!

[Root @ lhmnt] # setfacl-mm: rwx/mnt/dir/[root @ lhmnt] # getfacl/mnt/dir/getfacl: Removingleading '/'fromabsolutepathnames # file: mnt/dir/# owner: root # group: rootuser: rw-group: --- mask: rwxother: --- default: user: rw-default: user: sunsky: rwxdefault: group: --- default: mask: rwxdefault: other: --- [root @ lhmnt] # su-sunskyWellcometoLinuxWorld [sunsky @ lh ~] $ Bash/mnt/dir/sunskybash:/mnt/dir/sunsky: Permissiondenied

It's strange, why have I changed mask to rwx, and the valid effect does not appear again? Why does sunsky still fail to get the execution permission?

Now let's take a look at the ACL permission of the/mnt/dir/sunsky file.

[Root @ lhmnt] # getfacl/mnt/dir/sunskygetfacl: Removingleading '/'fromabsolutepathnames # file: mnt/dir/sunsky # owner: root # group: rootuser :: rw-user: sunsky: rwx # valid tive: rw-group: --- mask: rw-other ::---

Through viewing, we found that in the/mnt/dir/sunsky file, the acl permission settings for sunsky are still # valid tive: rw-. Why?

It turns out that the mask we modified/mnt/dir is only valid for the newly generated files under the/mnt/dir directory, affected by the umask value of the traditional permission, the ACL's mask setting becomes invalid because it already has the permissions of the consortium. Therefore, we can solve this problem by using the-R recursive option mentioned above to re-Modify the mask permission of all files in the/mnt/dir directory!

[Root @ lhmnt] # su-sunskyWellcometoLinuxWorld [sunsky @ lh ~] $ Echodate>/mnt/dir/sunsky [sunsky @ lh ~] $ Bash/mnt/dir/sunskyFriJul418: 32: 11CST2014

The above are all the operations for routine management of setfacl! I believe that as long as you master the above operations, you will not be embarrassed if you use the ACL in the future.