ACLs are abbreviations for access Control List, and the main purpose is to provide a detailed permission configuration outside of the traditional owner,group,others Read,write,execute permissions. ACLs can be used for single-user, single-file or directory-r,w,x permission specifications, which is useful for situations where special permissions are required.
What are the main areas that ACLs can control permissions on? He can focus on several projects:
User: You can configure permissions for users;
Group: Configure its permissions for groups as objects;
Default property (Mask): It is also possible to standardize the default permissions for new data when creating new files/directories in this directory;
ACL Configuration tips: Getfacl, Setfacl
Getfacl, Setfaclgetfacl: Gets the ACL configuration item for a file/directory;
SETFACL: Configure ACL Specification for a directory/file.
Setfacl command Usage
[[email protected] ~]# setfacl [-bkrd] [{-m|-x} ACL parameters] target file name options and Parameters:-m: Configure subsequent ACL parameters for the file to use, not with-X;-x: Remove subsequent ACL parameters, not with-M; b: Remove all ACL configuration parameters;-K: Remove the default ACL Parameters, about the so-called "default" parameters are described in the following example;-r: Recursive configuration ACL, that is, include the secondary directory will be configured;-D: Configure "default ACL parameters" means! Valid only for the directory, the new data in the directory references this default value |
The above is the ACL option function, then how to configure the ACL special permissions? There are many 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 with 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. If a file is configured with ACL parameters, his permission section will have one more + sign! But at this point you see the permissions and actual permissions may be a little error! So how do you see it? Just go through the getfacl!
Getfacl command Usage
[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, i.e. 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 above data is very easy to access it? The displayed data is preceded by #, which represents the default properties of the file, including the file name, the owner of the document, 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). In view of the above results, we have just configured the vbird1 for this file with R and X permissions!
# 2. For a specific group of ways:# Configuration specification: "g:[Group list]:[rwx]", for example, 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 shown in the table above, it is very easy to understand the meaning. However, you might find it strange that the mask is something. In fact, he is a bit like "effective permission" means! What he means is that the permissions configured by the user or group must exist within the scope of the mask's permission configuration to take effect, which is "Effective permissions (Effective permission)"
# 3. How to configure the effective permissions mask:# Configuration specification: "M:[RWX]", for example for just the file specification for only 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 all exist, only R! group::r--group:mygroup1:r-x #effective: r--mask::r--other::r--
|
# 1. Test first to see if you can access the directory using Myuser1? [Email protected] ~]$cd/srv/projecta-BASH:CD:/srv/projecta:permission denied<== do not enter! # 2. Start using root to configure permissions for this directory! [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 and see 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<== really can't write to!
|
# 1. Test first to see if you can access the directory using Myuser1? [Email protected] ~]$cd/srv/projecta-BASH:CD:/srv/projecta:permission denied<== do not enter! # 2. Start using root to configure permissions for this directory! [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 and see 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<== really can't write to!
|
# 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# Watch it! There are indeed inheritance! Then we use Getfacl again to confirm 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::---
|
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Linux-Host Detail permission planning: Use of ACLs