An ACL is an abbreviation for Access Control List. The basic purpose is to provide a detailed permission configuration beyond the Read,write,execute permissions of the traditional owner,group,others. ACLs can be used for single-user, single-file or folder-r,w,x permission specifications, which is useful for situations where special permissions are required.
What are the main areas in which ACLs can control permissions? He is primarily able to target several projects:
User: Ability to configure permissions for the consumer.
Group: Configure its permissions for groups as objects;
Default property (Mask): Also available for when creating new files/folders under this folder. The default permission to standardize new data.
ACL Configuration tips: Getfacl, Setfacl
Getfacl, Setfaclgetfacl: Gets the ACL configuration item for a file/folder.
SETFACL: Configure ACL Specification for a folder/file.
How to use the SETFACL command
[[email protected] ~]# setfacl [-bkrd] [{-m|-x} ACL parameters] target file name options and Parameters:-M: Configure the ACL parameters that may be used for the file, not with-X. -x: Remove the ACL parameters that may not be used with-M, B: Remove the full ACL configuration parameters,-K: Remove the default ACL parameters, about the so-called "default" parameters are described in the example;-r: Recursively configure ACLs. That is, the inclusion of the secondary folder will be configured,-D: Configure the "default ACL parameters" means! is only valid for a folder, the new data in the folder references this default |
The above is the ACL option feature. So how do you configure special permissions for ACLs? There are a lot of ways to configure special permissions, so let's start by talking about the most common way to configure a single user:
# 1. For specific users:# Configuration specification: "u:[user account List]:[rwx]", such as the permission specification for Vbird1 Rx:[Email protected] ~]#Touch Acl_test1[Email protected] ~]#ll Acl_test1-rw-r--r--1 root root 0 Feb 13:28 acl_test1[[email protected] ~]#setfacl-m U:vbird1:rx Acl_test1[Email protected] ~]#ll Acl_test1-rw-r-xr--+1 root root 0 Feb 13:28 acl_test1# The Permissions section has more than one +, and the original permission (644) looks very different! But how do we check it? [Email protected] ~]#setfacl-m u::rwx Acl_test1[Email protected] ~]#ll Acl_test1-rwxr-xr--+ 1 root root 0 Feb 13:28 acl_test1# No user list, on behalf of the configuration of the file owner, so the above to show the root permissions to become RWX!
|
As the simplest ACL configuration, these moves are configured using the "U: User: Permissions" method.
Please add-m to this option before configuration. Suppose a file is configured with ACL parameters. His permission section will have one more + number!
But at this point you see the permissions and actual permissions may be a little error! How do you observe it? Just go through the getfacl!
How to use the GETFACL command
[Email protected] ~]#getfacl filenameOptions and Parameters: The GETFACL option is almost the same as Setfacl. So bird brother here is exempt from the description of the option Ah!# Please list the permission contents of the Acl_test1 we have just configured:[Email protected] ~]#Getfacl Acl_test1# File:acl_test1<== description file name only. # Owner:root<== describes the owner of this file. The third user field that LL sees# Group:root<== the group to which this file belongs, i.e. the Fourth Group field that LL seesUser::rwx<== The user list bar is empty and represents the permissions of the owner of the fileUser:vbird1:r-x <== is configured as Rx for Vbird1 and is not the same as the owner! group::r--<== permissions for file groups are configured with only RMask::r-x<== The default effective permission (mask) for this fileother::r--<== Other people's rights.
|
The data above is easy to read, right? The displayed data is preceded by #, which represents the default property of the file, including the file name, the file owner, and the group to which the file belongs. Underneath the user, group, mask, and other are the configuration values that belong to different users, groups, and effective permissions (masks).
Look at the results above. The vbird1 we just configured has R and X permissions for this file.
# 2. For a specific group of ways:# Configuration specification: "g:[Group list]:[rwx]", such as the permission specification for Mygroup1 Rx:[Email protected] ~]#setfacl-m G:mygroup1:rx Acl_test1[Email protected] ~]#Getfacl Acl_test1# file:acl_test1# owner:root# group:rootuser::rwxuser:vbird1:r-xgroup::r--Group:mygroup1:r-x <== Here is the new part!More permissions for this group to configure! mask::r-xother::r--
|
Basically, the configuration of the group and the user is not much different! As seen in the table above, it is easy to understand the meaning.
It's just, you might think, strangely, what is that mask? In fact, he's kind of like "effective permission"!
The implication is that the permissions configured by the user or group must be within the scope of the mask's permission configuration to take effect. This is "Effective permissions (Effective permission)"
# 3. How to configure the effective permissions mask:# Configuration specification: "M:[RWX]", for example, the only file specification for just R:[Email protected] ~]#setfacl-m m:r Acl_test1[Email protected] ~]#Getfacl Acl_test1# file:acl_test1# owner:root# group:rootuser::rwxuser:vbird1:r-x #effective: r-- <==vbird1+mask are present. It's just r! group::r--group:mygroup1:r-x #effective: r--mask::r--other::r--
|
# 1. Try it out first. Can I access the folder using Myuser1? [Email protected] ~]$cd/srv/projecta-BASH:CD:/srv/projecta:permission denied<== do not enter! # 2. Start with root to configure permissions for this folder! [Email protected] ~]#setfacl-m u:myuser1:rx/srv/projecta[Email protected] ~]#getfacl/srv/projecta# file:srv/projecta# owner:root# group:projectauser::rwxUser:myuser1:r-x <== still want to see if there is a successful configuration oh. Group::rwxmask::rwxother::---# 3. Or you have to use Myuser1 to test the results! [[email protected] ~]$ cd/srv/projecta [[email protected] projecta]$ ll-a drwxrws---+ 2 root projecta 4096 Feb 27 11:29. <== You can actually query the file name drwxr-xr-x 4 root root 4096 Feb 27 11:29. [[email protected] projecta]$ touch testing touch:cannot Touch ' testing ': Permission denied <== is really not able to write!
|
# 1. Try it out first. Can I access the folder using Myuser1? [Email protected] ~]$cd/srv/projecta-BASH:CD:/srv/projecta:permission denied<== do not enter! # 2. Start with root to configure permissions for this folder. [Email protected] ~]#setfacl-m u:myuser1:rx/srv/projecta[Email protected] ~]#getfacl/srv/projecta# file:srv/projecta# owner:root# group:projectauser::rwxUser:myuser1:r-x <== still want to see if the configuration is successful Oh! Group::rwxmask::rwxother::---# 3. Still have to use Myuser1 to test the results! [Email protected] ~]$cd/srv/projecta[Email protected] projecta]$ll-aDrwxrws---+ 2 root projecta 4096 Feb 27 11:29.<== can actually query the file nameDrwxr-xr-x 4 root root 4096 Feb 27 11:29. [Email protected] projecta]$Touch TestingTouch:cannot Touch ' testing ': Permission denied<== is really not able to write!
|
# 4. How to configure the default permissions:# Configuration specification: "D:[ug]: User list: [rwx]"# let Myuser1 under/srv/projecta always have RX's default permissions![Email protected] ~]#setfacl-m d:u:myuser1:rx/srv/projecta[Email protected] ~]#getfacl/srv/projecta# file:srv/projecta# owner:root# group:projectauser::rwxuser:myuser1:r-xgroup::rwxmask::rwxother::---Default:user :: rwxDefault:user:myuser1:r-xDefault:group::rwxdefault:mask::rwxdefault:other::---[[email protected] ~]#cd/srv/projecta[Email protected] projecta]#Touch Zzz1[Email protected] projecta]#mkdir zzz2[Email protected] projecta]#ll-d zzz*-RW-RW----+1 root projecta 0 Feb 14:57 zzz1DRWXRWS---+2 root projecta 4096 Feb 14:57 zzz2# Look at it. There are indeed inheritance! Then we use Getfacl again to confirm the look. [Email protected] projecta]# getfacl zzz2# file:zzz2# owner:root# group:projectauser::rwxuser:myuser1: R-xgroup::rwxmask::rwxother::---default:user::rwxdefault:user:myuser1:r-xdefault:group::rwxdefault:mask:: Rwxdefault:other::---
|
Linux-Host Detail permission planning: Use of ACLs