In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)06/03 Report--
Table of contents:
(1) use ACL to authorize users
(2) set mask permissions
(3) set default permissions (can only be set for directories)
(1) use ACL to authorize users
(1.1) if we now have a requirement that there is a file file in the system, we need to set the permissions of tom on file files to "rmuri -", the permissions of bob users on file files to "rw-", the permissions of mary users on file files to "- -", and the permissions of jerry users on file files to "rmurx". At this time, there is no way to meet the requirements by using the conventional permission setting of the group owner. If you are required to set acl permissions for a specific user or group, you should consider using acl.
(1.2) now we go to the / opt/ directory, and then copy the / etc/hosts file to the current directory. At this time, we find that the permissions of the other user of the hosts file are readable (figure 1-1), so when we modify the hosts file as a tom user, we find that it cannot be modified successfully (figure 1-2 and figure 1-3).
# cp / etc/hosts.
# getfacl hosts
If we want tom users to be able to modify the hosts file at this time, we should use the setfacl command to set it up. We set the permission to set rwx to the tom user for the hosts file, and we find that the tom user already has an acl permission in the hosts file (figure 1-4). At this time, we can use the tom user to add information to the hosts file normally (figure 1-5).
# setfacl-m u:tom:rwx hosts--- sets rwx permissions to tom users for hosts files
# getfacl hosts--- query the permissions of the current hosts file
(1.4) if we want to revoke the acl permissions set for the tom user, we can use the setfacl-x command, and we find that there is no acl permission set for the tom user in the system (see figure 1-6).
# setfacl-x u:tom hosts--- cancels acl permissions set to tom users
(2) set mask permissions
We first set acl permissions for both tom and jerry users (figure 2-1). Now we have a certain file or directory in the company, and we have set acl access control permissions for many users, but now we need to maintain the file or directory. At this time, we need not allow anyone to write this file, and then open the file permissions to the corresponding users after the file is maintained. At this point, we can use mask permissions, which is equivalent to a layer of mask code to cover the current user's permissions, and then carry out maintenance operations. We can use the setfacl-m command operation (figure 2-2). At this time, we find that the acl permissions previously set to tom users and jerry users are covered by the new mask code "Rafe -". After we use "# setfacl-m mmlur-hosts" to operate the mask code. It is found that the hosts file cannot be modified successfully at this time when editing the hosts file as the tom user (figure 2-3).
# setfacl-m u:tom:rwx hosts--- sets acl permissions for tom users
# setfacl-m u:jerry:rwx hosts--- sets acl permissions for jerry users
# setfacl-m mvv hosts-hosts--- sets a mask mask code to the mask file
(2.2) if we want to remove the mask code, we only need to reset the acl permissions for one of the users, so that all users' original acl permissions will take effect.
# setfacl-m u:tom:rwx hosts--- sets the ACL value of tom users
# getfacl hosts--- queries the acl status of hosts files
(2.3) now we set the mask value of the hosts file to unreadable, unwritable and unexecutable. At this time, we find that although the mask permission of the hosts file is "- -", because there is readable permission in the other permission of the hosts file, the tom user will read the hosts file as other and can read the hosys file normally. Only we remove the readable permission of the hosys file. The tom user cannot read the file at this time.
Note: our summary is that if the permission of mask is set to "- -", then the permission of other takes effect; if the permission of mask is set to non-"- -", then the permission of mask takes effect.
# setfacl-m hosts hosts-hosts--- sets the mask value to unreadable, non-writable, and non-executable
Now that we reset the permissions of both the tom user and the jerry user to RMX, and then set the value of mask to rwx (figure 2-7), when we use the tom user to try to write to the hosts file, we find that it is still unwritable (figure 2-8). Our conclusion is that if you set the permission to rmurx but not w to the user, if you want to set the permission to w in mask, it is still impossible to make the writable permission of the file take effect. If we add w permissions to the permissions of other, tom and jerry users still cannot have writeable permissions for hosts files, which means that the permissions set by setacl are higher than those set in other.
# setfacl-m u:tom:r-x hosts--- sets the acl of tom users to rMurx
# setfacl-m u:jerry:r-x hosts--- sets the acl of jerry users to rMurx
# setfacl-m m::rwx hosts--- sets the mask value of the hosts file to rwx
# getfacl hosts--- queries the acl status of hosts files
(2.5) if we want to set acl permissions on the user group, for example, we set the tom group to have read, writeable and executable permissions, and then we want the bob user who does not have the permission to have the permission of the tom group, what we do at this time is to add the bob user to the tom group, and then log the bob user out of the login and then log in to the bob user again, then the bob user has the permission of the tom group.
# setfacl-m g:tom:rwx file--- sets acl permissions on tom groups
(3) set default permissions (can only be set for directories)
Let's first create a rh234 directory under the / opt/ directory of the vms002 host.
# mkdir rh234--- create a directory for rh234
# getfacl rh234/--- gets the permissions of the created directory
Then we set up rwx permissions for tom for new files or directories created in the rh234 directory, regardless of who created them in the rh234 directory, but not rh234 itself. Then we create a root1 file under the rh234 directory, and at this time we find that the permissions of the created root1 files inherit the permissions of the tom user rwx, but because the operating system stipulates that the highest permissions for creating files are 644, so the default permissions for files are rw-, so when creating files, no matter what method is used, there is no way to create files that contain x permissions by default.
# setfacl-m d:u:tom:rwx rh234/--- setting has rwx permission for tom regardless of who created the new file or directory in the rh234 directory, but does not include rh234 itself
# touch rh234/root1--- create a root1 file in the rh234 directory
# getfacl rh234/root1--- queries the acl permissions of root1 directories
Then we try to use the jerry user to create a file. We first set the jerry user acl to have rwx permissions on the directory rh234 (figure 3-3), and then we create a jerry1 file. At this time, we create a jerry1 file that inherits the rwx rights of the tom user. At the same time, in order to meet the system default requirements for file creation, the final jerry1 file permission is rw- (figure 3-4).
# setfacl-m u:jerry:rwx rh234/--- set jerry user to have read, write and executable permissions on directory rh234
# getfacl rh234/--- gets permission information of directory rh234
# touch rh234/jerry1
# getfacl rh234/jerry1
We then use the jerry user to create a jerry2 directory under the / opt/ directory, and we find that the created directory still inherits the rwx permissions that the default tom user has when executing.
# mkdir rh234/jerry2--- create a directory jerry2
# getfacl rh234/jerry2
(3.5) although the tom user has permissions for the newly added files in the rh234 directory, the tom user cannot create files in the rh234 directory because we do not set acl permissions for the tom user for the rh234 directory.
(3.6) if we want to remove the default permissions for tom users, we can use the "# setfacl-x d:u:tom rh234/" command. We found that the previously created files still have tom user readable and writeable permissions that will not be taken back (figure 3-7), but if we create a new file, we will no longer inherit the relevant permissions that tom users can execute (figure 3-8).
# setfacl-x d:u:tom rh234/--- cancels the default setting of inheriting the relevant permissions of the tom user for files in the 134 directory
# getfacl rh234/jerry1--- acquires acl permissions for previously created files in the rh234 directory
# mkdir rh234/root2
# getfacl rh234/root2
-this is the end of this article. Thank you for reading-
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.