First, why use ACLs
Let's start by simply reviewing the Linux file permissions.
Under Linux, objects that can operate on a file (or resource) are divided into three categories: file owner
Group, note that it is not necessarily the group where the file owner is located, other (others) and for each class of
Do not separately define read, write and Execute/search permissions (not discussed here suid, Sgid and
Sticky bit settings)
With the Ls-l command, we can list the permissions of a file.
Code:
[Email protected] ~]$ ls-l
-RW-RW----1 Leonard admin 0 Jul 3 20:12 test.txt
This is explained here for Test.txt this file Leonard user (as file owner) has Read & write
Permissions. All Users (group) belonging to the Admin group have read & Write permissions. Any other user (other)
Do not have any permissions for the file
If we want John now, this user can read and write to the Test.txt file as well. I would probably think of it myself.
Here are a few options (assuming John is not part of the admin group)
1. Add read and Write permissions to the other category of the file. So since John will be classified as the other category, then
He will also have access to read and write.
2. Add John to the admin group. Then John will be classified as group, then he will have read and write permissions.
3. Set sudo so that John can operate on Test.txt as Leonard to gain read and write access.
The problem with the first approach is that all users will have read and write operations on Test.txt, which is obviously undesirable.
The problem with the second approach is that John is given too much authority. All files that belong to the Admin group, John can hold
has its equivalent permission.
A third approach can be achieved by restricting only John users to one person having read and write access to the Test.txt file. But need
Strict format control of the sudoers file. And when the number of files and a lot of users, this method is quite
The ground is not flexible.
It doesn't seem like there's a good solution. In fact, the problem is in the Linux file permissions, for other
The definition is too extensive to restrict permissions to a user who does not belong to file owner and group. So
The Access Control List (ACL) is used to help us solve this problem.
Simply put, an ACL is a way to set permissions on a file/folder for a specific user or group of users. Need
There are only three commands to master: Getfacl, Setfacl, Chacl
You can install the ACL RPM package before the next discussion.
Code:
# RPM-IVH libacl-2.2.39-1.1 acl-2.2.39-1.1.i386.rpm
If the configuration is good, yum can install both packages directly
# yum-y Install Libacl ACL
Additional support for disk partitioning is also required
Permanently enable ACLs. I'm using my own zoning/data as an example.
# Vi/etc/fstab
Label=/data/data ext3 defaults,acl 1 2
Reload the/data partition after ACL parameters are enabled
# Mount-o Remount/data
# Cat/etc/mtab | Grep/data
/dev/sda5/data ext3 rw,acl 0 0
The above information indicates that the ACL function for the partition has been loaded properly
ii. noun definitions of ACLS
Let's take a look at the definition of each noun in the ACL. Most of these nouns I picked off from the man page, though somewhat dull,
But it would be helpful to understand the following:
ACLs are made up of a series of access entry. Each access entry defines a specific category that can be used to
The operation permissions that the file has. Access Entry has three components: Entry tag type, qualifier
(optional), permissions
Let's first look at the most important entry tag type, which has the following types
Acl_user_obj: Equivalent to File_owner permissions in Linux
Acl_user: Defines the permissions that additional users can have on this file
Acl_group_obj: Equivalent to GROUP permissions in Linux
Acl_group: Defines the permissions that additional groups can have on this file
Acl_mask: Defines the maximum permissions for Acl_user, Acl_group_obj, and Acl_group (which I'll discuss below)
Acl_other: Equivalent to other permissions in Linux
Let's take an example to illustrate this. Now we'll use the GETFACL command to see a defined ACL file.
Code:
[Email protected] data]# Getfacl test.txt
# File:test.txt
# Owner:root
# group:family
user::rw-
user:zyq:rw-
group::rw-
group:jackuser:rw-
mask::rw-
Other::---
The previous three defines the file name with #, the file owner and the file owning group. This information does not have much effect, I
We can use--omit-header to omit them.
user::rw-defines acl_user_obj, stating that file owner has read and write permissions
user:zyq:rw-defines the acl_user so that the user Zyq has read and write access to the file, realizing the purpose we were to achieve at the outset.
group::rw-defines acl_group_obj, stating that the file GROUP has read and write permissions
group:jackuser:rw-defines the acl_group so that the JackUser group has read and write permissions on the file
mask::rw-defines the permissions for Acl_mask for Read and write
Other::---defines acl_other without any permissions to manipulate this file
From here we can see that ACLs provide functionality that we can define for specific users and groups of users. Well, then we'll come.
Take a look at how to set an ACL for a file
Third, how to set ACL file
First, let's talk about the format of the ACL file. From the example above, we can see that each access Entry
Are made up of three fields separated by the: number. The first one is entry tag type
The user corresponds to Acl_user_obj and Acl_user
Group corresponds to Acl_group_obj and Acl_group.
Mask corresponds to the Acl_mask
Other corresponds to the Acl_other
The second field is called qualifier. The Zyq and JackUser groups in the example above. It defines specific users and user groups
Permissions for the file. We can also find that only user and group have qualifier, others are empty
The third field is the one we are familiar with. It's defined like Linux permissions, and there's not much to say.
Let's take a look at how to set the ACL for this file to test.txt it to meet our requirements above
The first file has no extra attributes for the ACL
Code:
[email protected] data]# ll Test.txt
-rw-r--r--1 root root 0 12-27 22:55 test.txt
[Email protected] data]# Getfacl test.txt
# File:test.txt
# Owner:root
# Group:root
user::rw-
group::r--
other::r--
[Email protected] data]# getfacl-c test.txt
user::rw-
group::r--
other::r--
We first let the user Zyq have read and write access to the Test.txt file.
Code:
[Email protected] data]# setfacl-m U:ZYQ:RW test.txt
[Email protected] data]# getfacl-c test.txt
user::rw-
user:zyq:rw-
group::r--
mask::rw-
other::r--
At this point we can see that the ZYQ user has read and write access to the file in the ACL. This time if we
Check Linux permissions and we'll find a different place.
Code:
[email protected] data]# ll Test.txt
-rw-rw-r--+ 1 root root 0 12-27 22:55 test.txt
There is a + number at the end of the file permissions. When any one file has a value of acl_user or Acl_group, I
You can call it an ACL file. The + number is used to prompt us.
We can also find that Acl_mask is also defined when a file has a value of Acl_user or Acl_group
Next, let's set the JackUser group to have Read permission
Code:
[email protected] data]# ll Test.txt
-rw-rw-r--+ 1 root root 0 12-27 22:55 test.txt
[Email protected] data]#
[Email protected] data]# setfacl-m g:jackuser:r test.txt
[Email protected] data]# getfacl-c test.txt
user::rw-
user:zyq:rw-
group::r--
group:jackuser:r--
mask::rw-
other::r--
[email protected] data]# ll Test.txt
-rw-rw-r--+ 1 root root 0 12-27 22:55 test.txt
Here we have completed the above requirements. Isn't it simple?
Iv. Acl_mask and effective permissions
Here we need to focus on acl_mask, because this is another key to mastering the ACL
In Linux file permissions we all know, for example, for rw-rw-r--, the rw-in the second group refers to the file
The permissions for the group. But in the ACL, this is only true if the acl_mask does not exist. If the file has Acl_mask
Value, then the rw-represents the mask value and is no longer a group permission.
Note: If you set the Mask permission before, user and group, then the User/group permissions conflict, when the mask permission, the final effective permissions will be displayed in effective.
$ setfacl-m u:user_name:rwx,g:user_name:rwx file/filename, user group and user authorization at the same time, to the user-oriented.
$ setfacl-m m::r file/filename Master has the highest priority.
Priority level from high to low is Master/default->user->group
The knowledge of default is covered in the 5th.
Let's take a look at the following example
Code:
[email protected] data]# ll test.sh
-rwxrw-r--1 root Family 0 12-27 23:04 test.sh
Here is a description of test.sh files only file owner:root has read, write, execute/search permissions. Family
The group has only read and write permissions. Now we want to let the user Zyq also have the same permissions as root for test.sh.
Code:
[Email protected] data]# setfacl-m u:zyq:rwx test.sh
[Email protected] data]# getfacl-c test.sh
User::rwx
User:zyq:rwx
group::rw-
Mask::rwx
other::r--
Here we see that Zyq already has rwx permissions. The mask value is also set to rwx. That's because it prescribes acl_user,
Maximum values for Acl_group and Acl_group_obj
Now let's look at Test.sh's Linux permissions, which has become
Code:
[email protected] data]# ll test.sh
-rwxrwxr--+ 1 root Family 0 12-27 23:04 test.sh
So what happens if the users of the family group want to execute the TEST.SH program now? It will be denied permission to deny the original
The reason is that the user of the family group has only read and write permissions. The rwx shown here is the value of Acl_mask instead of the group
The permissions
So from here we can know that if a file is followed by a + tag, we need to use GETFACL to confirm its right
To avoid confusion
Let's go on to see an example.
If we now set test.sh mask to read only, then will the users of the family group have write permission?
Code:
[Email protected] data]# setfacl-m mask::r test.sh
[Email protected] data]# getfacl-c test.sh
User::rwx
USER:ZYQ:RWX #effective: r--
group::rw-#effective: r--
mask::r--
other::r--
At this time we can see Acl_user and acl_group_obj next to a #effective:r--, what does that mean?
Let's go back to the definition of acl_mask. It prescribes the largest acl_user, Acl_group_obj and Acl_group.
Permissions. So in our example, their maximum permissions are read only. Although we're here for Acl_user and Acl_group_obj,
Other permissions have been set, but they really have only read permissions.
When we look at Test.sh's Linux file permissions, its group permissions also show the value of its mask (i.e. r--)
Code:
[email protected] data]# ll test.sh
-rwxr--r--+ 1 root Family 0 12-27 23:04 test.sh
V. Default ACL
All we're talking about is the access ACL, which is the file. Let me briefly explain the default ACL. Default ACL
is the default ACL setting for a directory, and the files established in this directory inherit the ACL for this directory
Let's also do a test note.
For example, now Leonard user has created a dir directory
Code:
[Email protected] data]$ mkdir Mydir
I hope all the files created in this directory can be accessed by smbuser users. Then we should set the default ACL on the Mydir directory
I first use the root user to create a Mydir folder in/data/, and then set the default user permission for this folder to Smbuser can rw-create a Mydir file in the Test.txt directory as root. Do not limit the other, then switch to Smbuser. Discover Smbuser Users can modify the contents of the Test.txt file but cannot create and delete files/folders in the Mydir directory
Code:
[[email protected] data]# ID
Uid=0 (Root) gid=0 (root) groups=0 (root)
[email protected] data]# ll mydir/
Total 0
[Email protected] data]# Getfacl mydir/
# file:mydir/
# Owner:root
# Group:root
User::rwx
Group::r-x
Other::r-x
[Email protected] data]# setfacl-m D:SMBUSER:RW mydir/
[Email protected] data]# Getfacl mydir/
# file:mydir/
# Owner:root
# Group:root
User::rwx
Group::r-x
Other::r-x
Default:user::rwx
default:user:smbuser:rw-
Default:group::r-x
Default:mask::rwx
Default:other::r-x
[Email protected] data]# CD mydir/
[email protected] mydir]# Touch test.txt
[Email protected] mydir]# Su-smbuser
[Email protected] ~]$ cd/data/mydir/
[[email protected] mydir]$ touch a
Touch: Unable to create "a": Insufficient permissions
[Email protected] mydir]$ RM test.txt
RM: Unable to delete "Test.txt": Insufficient permissions
[Email protected] mydir]$ echo Hello World>>test.txt
[email protected] mydir]$ cat Test.txt
Hello World
Here we can see that the ACL defines the default option, and the Smbuser user has the default read, write, excute/search permissions. However, you cannot delete and create files. After testing, it is found that the acl_user of the Mydir directory must be modified to Smbuser to Smbuser users to create and delete files/folders in the Mydir directory.
[Email protected] data]# setfacl-m u:smbuser:rwx mydir/
[Email protected] data]# getfacl-c mydir/
User::rwx
User:smbuser:rwx
Group::r-x
Mask::rwx
Other::r-x
Default:user::rwx
default:user:smbuser:rw-
Default:group::r-x
Default:mask::rwx
Default:other::r-x
[Email protected] data]# Su-smbuser
[Email protected] ~]$ cd/data/mydir/
[[email protected] mydir]$ touch a
[email protected] mydir]$ LL
Total 4
-rw-rw-r--+ 1 smbuser Family 0 12-27 23:43 A
-rw-rw-r--+ 1 root root 12-27 23:33 test.txt
[Email protected] mydir]$ RM *-RF
[Email protected] mydir]$
In the following experiment we see that the files or folders created under Mydir are automatically added with the default permissions
[Email protected] mydir]# Su-smbuser
[Email protected] ~]$ cd/data/mydir/
[email protected] mydir]$ LL
Total 0
-rw-rw-r--+ 1 root root 0 12-27 23:48 a
-rw-rw-r--+ 1 root root 0 12-27 23:48 test.tt
[Email protected] mydir]$ RM *-RF
[email protected] mydir]$ Touch test.txt
[email protected] mydir]$ LL
Total 0
-rw-rw-r--+ 1 smbuser Family 0 12-27 23:48 test.txt
[Email protected] mydir]$ getfacl-c test.txt
user::rw-
user:smbuser:rw-
Group::r-x #effective: r--
mask::rw-
other::r--
[Email protected] mydir]$ mkdir Smbuserdir
[Email protected] mydir]$ getfacl-c smbuserdir/
User::rwx
user:smbuser:rw-
Group::r-x
Mask::rwx
Other::r-x
Default:user::rwx
default:user:smbuser:rw-
Default:group::r-x
Default:mask::rwx
Default:other::r-x
[email protected] mydir]$ LL
Total 4
drwxrwxr-x+ 2 Smbuser family 4096 12-27 23:49 Smbuserdir
-rw-rw-r--+ 1 smbuser Family 0 12-27 23:48 test.txt
Vi. ACL-related commands
In the previous example we have noticed that the GETFACL command is the ACL used to read the file, and Setfacl is the acess ACL used to set the file. There is also a chacl that is used to change the file and directory of the access ACL and the Default ACL. Its specific parameters you can go to see the man page. I just want to mention chacl-b. It can completely delete the ACL properties of a file or directory (including the default ACL). For example, if you use Setfacl-x to delete all of the file's ACL attributes, the + sign will still appear at the end of the file. So the correct way to delete is to use Chacl-b
When using CP to copy files we can now add the-P option. This will also copy the file's ACL attributes when copying the file. Warning for ACL properties that cannot be copied
The MV command will move the file's ACL properties by default. Also give a warning if the operation is not allowed
Seven. Points to note
If your filesystem does not support ACLs, you may need to re-mount your file system
Mount-o remount, ACL [Mount Point]
If you change the Linux file permissions with the chmod command, the corresponding ACL values will change. Conversely, if you change the value of the ACL, the corresponding file permissions will change.
Eight. References
1. Man ACL personally feel the person page has been told more detailed, but the above noun more looks more cumbersome
2. http://www.suse.de/~agruen/acl/linux-acls/online/If you have good English, take a look at this introduction to the POSIX ACL, which has a number of good examples
ACLs in Linux