Traditional permissions only have three kinds of identities (owner, group, others) with three kinds of permissions (r,w,x), and there is no way to simply target a particular user or a group to set specific permissions requirements, you have to use the ACL this mechanism!### what is ACL and how to support Startup Aclacl is an abbreviation for access Control List, and the main purpose is to provide detailed permission settings beyond 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. Mainly for several projects: * User: You can set permissions for the user; * Group: Set its permissions on the group as an object; * Default property (Mask): You can also specify the default permissions for new data when creating new files/directories in this directory; traditional Linux permissions can only be set on a user, a group, and other people other than this group, and cannot design permissions for a single user or individual. And the ACL is to change the problem Ah! Well, after a little bit of understanding, let's look at how to get your filesystem to support ACLS! * How to launch ACL the original ACL is an additional support item for the Unix-like operating system, but since the Linux system has been eager to set the authority details in recent years The ACL is now almost pre-programmed to join all common Linux file system mount parameters (EXT2/EXT3/EXT4/XFS, etc.)!### ACL setting technique: Getfacl, setfacl How to set and observe the ACL? It's easy to use these two commands: * Getfacl: Get ACL settings for a file/directory; * SETFACL: Set ACL specification for a directory/file. ---* SETFACL instruction usage Introduction and simplest "U: Account: Permission" Setting "[[[Email protected] ~]# setfacl [-BKRD] [{-m|-x} ACL parameters] target file name options and Parameters:-M: Set subsequent The ACL parameter is used by the file, not with-X;-X: Remove the subsequent ACL parameters, not with-M; B: Remove the "All" ACL setting parameters;-K: Remove the "preset" ACL parameter, which is described in the following example for the so-called "preset" parameter;-r: Recursive settingACLs, which include the sub-directories, are set up;-D: Sets the meaning of "preset ACL parameters"! Only the directory is valid, and the new data in that directory will reference this default "How do I set special permissions for ACLs?" Special permissions are set in many ways, let's talk about the most common, is for a single user to set the way: ' # 1. For a specific user: # Setup Specification: "u:[user account List]:[rwx]", such as the Permissions specification for Vbird1 rx: [[email protected] ~]# Touch acl_test1[[email Protected] ~]# ll acl_test1rw-r--r--. 1 root root 0 Jul 17:33 acl_test1[[email protected] ~]# setfacl-m u:vbird1:rx acl_test1[[email protected] ~] # ll acl_test1-rw-r-xr--+ 1 root root 0 Jul 17:33 acl_test1# Permissions section more than a plus, and with the original permission (644) looks very different! But how do you check it? [[email protected] ~]# setfacl-m u::rwx acl_test1[[email protected] ~]# ll acl_test1-rwxr-xr--+ 1 root root 0 J UL 17:33 acl_test1# in the set value of the no user list, representing the setting of the file owner, so the above shows that root permissions become RWX! "---* getfacl instruction usage" [[email protected] ~]# getfacl filename Options and Parameters: Getfacl options are almost identical to Setfacl!# please list the contents of the acl_test1 we have just set: [[email protected] ~]# getfacl acl_ test1# file:acl_test1 <== Description file name!# owner:root <== describes the owner of this file, that is, the third user field that Ls-l sees # Group:root <== the group that this file belongs to, i.e. LS-L See the Fourth Group field user::rwx <== the consumer list bar is empty, representing the permissions of the owner of the file User:vbird1:r-x <== the permission to Vbird1 is set to Rx, not with the owner!group::r--<== The permission settings for the file group are only R mask::r-x <== the effective permission (mask) of this file preset other::r--<== other people's rights! "---* permission settings for a specific group of groups:" G: Group name: Permission "' # 2. For specific groups: # Setup Specification: "g:[Group list]:[rwx]", for example, 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 section! More permission settings for this group! mask::r-xother::r--'---* for effective permission settings: "M: Permissions" You should be surprised what that mask is? In fact, he is a bit like "effective permission" means! What he means is that the permissions set by the user or group must exist in the mask Within the scope of the permission set, this is the "Effective permissions (Effective permission)" We give an example, as follows: "# 3. The setting of the effective permission Mask # Setting Specification: "M:[RWX]", for example for just the file specification for only R: [[email protected] ~]# setfacl-m m:r Acl_test1[[email pro Tected] ~]# getfacl acl_test1# file:acl_test1# owner:root# group:rootuser::rwxuser:vbird1:r-x #effective: r--<==vbi Rd1+mask all exist, only R, X will not take effect group::r--group:mYgroup1:r-x #effective: The collection of r--mask::r--other::r--' vbird1 and mask found that only R exists, so vbird1 only has R permissions, there is no x permission! This is the Mask function! We can avoid accidentally opening certain permissions to other users or groups by using mask to regulate the maximum allowable permissions. Next, let's test if I use root or Pro1 to/srv/projecta add a file or directory, whether the file or directory can have ACL settings? This means that the ACL's permission settings can be "inherited by the secondary directory"? Try it out first: "[[[email protected] ~]# cd/srv/projecta[[email protected] ~]# touch abc1[[email protected] ~]# mkdir abc2[[email protected] ~]# ll-d abc*-rw-r--r--. 1 root projecta 0 Jul 17:49 ABC1 drwxr-sr-x. 2 root projecta 6 Jul 17:49 ABC2 "You can obviously find that there is no + on the back of the permission, which means that the ACL attribute is not inherited. If you want the ACL to inherit the data under the directory, you have to do the following!---* Use the default Permissions to set the ACL permissions for future files of the directory Inherit "D:[u|g]:[user|group]: Permission" ' # 4. How to set the default permissions: # Setting Specification: "D:[ug]: User list: [rwx]" # Let Myuser1 under the/srv/projecta always have RX preset permission! [[email protected] ~]# setfacl-m d:u:myuser1:rx/srv/projecta[[email protected] ~]# getfacl/srv/projecta# file:srv/projecta# owner:root# group:projecta# Flags:-s-user::rwxuser:myuser1:r-xgroup::rwxmask::rwxother::---Default:user::rwxdefault:user:myuser1:r-xdefault:group::rwxdefault:mask::rwxdefault:other::---"If you want to let the ACL All the properties disappear and how to deal with them? Through the "Setfacl-b file name" Can! However, you cannot cancel ACL permissions such as files that already exist
Linux Learning-Detail permission planning for hosts: using ACLs
