Use of ACLs for Linux learning notes

What is an ACL
ACL is the abbreviation of Access Control List, the main purpose is to provide the traditional owner,group,others
Read,write,execute permission settings outside of the permissions. ACLs can be used for single-user, single-file or directory-based
The R,W,X permission specification is useful for situations where special permissions are required.
What can the ACL do to control permissions? He can focus on several projects:
User: You can set permissions for users;
Group: Set its permissions on the group as an object;
Default property (Mask): It is also possible to standardize the default permissions for new data when a new file/directory is created in that directory;

How to start an ACL
Because ACLs are an additional support project for traditional unix-like operating system permissions, the use of ACLs must be supported by a file system
The right to hold. Most of the file systems currently have ACL support, including ReiserFS, Ext2/ext3, JFS, XFS, and so on.
In our CentOS 5.x, the preset use of EXT3 is supported by the boot ACL, as to whether your file system supports ACLs
Can look like this:
# Mount <== Direct access to mount parameters function
/dev/hda2 on/type ext3 (rw)
/dev/hda3 on/home type ext3 (rw)
# Suppose we just look at the two devices. But did not see the ACL
# dumpe2fs-h/dev/hda2 <== by Superblock content to query
.... (omitted earlier) ....
Default Mount Options:
User_xattr ACL
.... (omitted later) ....

It is not possible to see the actual project from Mount simply, as the new distributions will often take the initiative to join some tacit
As shown in the table above, in fact CentOS 5.x in the case of presets (default mount options:) To get you into the ACL.
Support!, what if your system does not help you add ACL support? Then you can do this:
# Mount-o Remount,acl/
# mount
/dev/hda2 on/type ext3 (RW,ACL)
# That's it, but if you want it to take effect every time you turn it on, do it:
# Vi/etc/fstab
LABEL=/1/EXT3 Defaults,acl 11
If you are unsure or do not use DUMPE2FS to observe your file system, then it is recommended that the above/etc/fstab be directly inside
The contents of the changes can be

ACL Setup tips: Getfacl, Setfacl
OK, let your filesystem start ACL support, then how to set and observe the ACL? It is easy to use these two commands to:
Getfacl: Gets the ACL setting item for a file/directory;
Setfacl: Sets the ACL specification for a directory/file.
SETFACL instruction Usage
#setfacl [-BKRD] [{-m|-x} ACL parameter] target file name
Options and Parameters:
-M: Set subsequent ACL parameters for file use, not with-X;
-X: Do not share with-m except for subsequent ACL parameters;
-B: Remove all ACL setting parameters;
-K: Removes the default ACL parameters, as described in the following example for the so-called "preset" parameters;
-R: Recursive ACL, that is, include the sub-directory will be set up;
-D: Set the meaning of "preset ACL parameters"! Only valid for directory, new data in this directory will reference this default value
The above is the ACL option function, how to set the ACL special permissions? There are many ways to set special permissions, and we
First of all, the most common is to set the way for a single user:
1. For specific users:
Setup specification: "u:[user account List]:[rwx]", such as the permission specification for Vbird1 Rx:
# Touch Acl_test1
# ll Acl_test1
-rw-r--r--1 root root 0 Feb 13:28 acl_test1
# setfacl-m U:vbird1:rx Acl_test1
# 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 to check it?
# 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 user set the file owner, so the above to show the root permissions to become RWX!

GETFACL instruction Usage
#getfacl filename
Options and Parameters:
Getfacl's options are almost identical to those of Setfacl! So brother Bird, here's a description of the option.
Please list the permission content of the acl_test1 we have just set up:
# Getfacl Acl_test1
# file:acl_test1 <== Description file name
# Owner:root <== describes the owner of this file, i.e. the third user field that LL sees
# Group:root <== The group that this file belongs to, i.e. the Fourth Group field that LL sees
user::rwx <== The user list bar is empty and represents the permissions of the owner of the file
User:vbird1:r-x <== is set to Rx for Vbird1, not the same as the owner!
group::r--<== permission set for file groups is only R
Mask::r-x <== Effective permissions for this file preset (mask)
other::r--<== Other people have permissions
The above data is very easy to look up, the displayed data is preceded by the #, representing the default properties of this file, including the file name, files
The owner and the group to which the file belongs. The user, group, mask, and other that appear below are different users, groups, and effective rights
Limit (mask) setting value. Judging from the above results, we have just set the vbird1 to have R and X permissions for this file.

2. How to target a specific group:
Setup specification: "g:[Group list]:[rwx]", for example, the permission specification for Mygroup1 Rx:
# setfacl-m G:mygroup1:rx Acl_test1
# Getfacl Acl_test1
# File:acl_test1
# Owner:root
# Group:root
User::rwx
User:vbird1:r-x
group::r--
Group:mygroup1:r-x <== Here is the new section, more permission settings for this group
Mask::r-x
other::r--
Basically, there is no big difference between group and user settings! As shown in the table above, it is very easy to understand the meaning. However, you should
It would be strange to say, what is that mask about? In fact, he's kind of like "effective permission"! What he means is:
The permissions set by the user or group must be within the scope of the mask's permission set to take effect, which is "effective permissions
(Effective permission) "Let us give an example, as shown below:
3. How to set the effective permission mask:
Set spec: "M:[RWX]", for example for just the file specification for only R:
# setfacl-m M:r Acl_test1
# Getfacl Acl_test1
# File:acl_test1
# Owner:root
# Group:root
User::rwx
User:vbird1:r-x #effective: r--<==vbird1&mask all exist, only R!
group::r--
Group:mygroup1:r-x
mask::r--#effective: r--

other::r--
The collection of vbird1 and masks found that only R exists, so Vbird1 has only the R permission, and there is no X permission
This is the function of mask. By using mask to regulate the maximum allowable permissions, you can avoid accidentally opening certain
Permissions to other users or groups. However, it is common to set the mask to rwx and then separate the
Users/groups to regulate their rights.
Examples:
/srv/projecta This directory allows myuser1 to access, but Myuser1 does not have the right to modify.
For:
Since Myuser1 is an independent user and group, and/srv is subordinate/under,/srv already has ACLs
The function. This can be done through the following settings:
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 set permissions for this directory!
# setfacl-m U:myuser1:rx/srv/projecta
# getfacl/srv/projecta
# file:srv/projecta
# Owner:root
# group:projecta
User::rwx
User:myuser1:r-x <== still have to see if it's set.
Group::rwx
Mask::rwx
Other::---
3. We still 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. <== 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 <== really can't write to

The above settings we have completed the previous task two of the follow-up requirements Oh! This is easy! Let's test it, if I use
Root or Pro1 to/srv/projecta add a file or directory, whether the file or directory can have ACL
Availability? This means that the ACL's permission settings can be "inherited" by the secondary directory to try it out first:
# cd/srv/projecta
# Touch ABC1
# mkdir ABC2
# ll-d abc*
-rw-r--r--1 root projecta
0 14:37 ABC1
Drwxr-sr-x 2 root projecta 4096 Feb 14:37 ABC2
You can clearly see that there is no + on the back of the permission, which means that the ACL attribute is not inherited. If you want to have ACLs at the bottom of the directory
The following data have inherited functions, then you have to do the following!

4. How to set the default permissions:

Set User Preset Mask:

#setfacl-M Mask::rx directory name or file name

[No D option means only valid for current directory]

Remove ACLs from a file or directory

#setfacl-B Directory name or file name

Setting specification: "D:[ug]: User list: [rwx]", d option indicates inheritance for current directory ACL settings
Keep Myuser1 under/srv/projecta. Rx Preset Permissions
[Email protected] ~]# setfacl-m d:u:myuser1:rx/srv/projecta
[Email protected] ~]# getfacl/srv/projecta
# file:srv/projecta
# Owner:root
# group:projecta
User::rwx
User:myuser1:r-x
Group::rwx
Mask::rwx
Other::---
Default:user::rwx
Default:user:myuser1:r-x
Default:group::rwx
Default:mask::rwx
Default:other::---

# 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 14:57 Zzz1
Drwxrws---+ 2 root projecta 4096 14:57 zzz2
# There are indeed inheritance, and then we use GETFACL to confirm again
# Getfacl ZZZ2
# FILE:ZZZ2
# Owner:root
# group:projecta
User::rwx
User:myuser1:r-x
Group::rwx
Mask::rwx
Other::---
Default:user::rwx
Default:user:myuser1:r-x
Default:group::rwx
Default:mask::rwx
Default:other::---
Through this project "default ACL permission SetPoint for directory", we can have these attributes inherited to the sub-directory
If you want to have the properties of the ACL all disappear "Setfacl-b file or directory name"

Use of ACLs for Linux learning notes