Shulou(Shulou.com)06/03 Report--

Special permissions on the Linux system

For example:

[root@centos730g ~] # ll / bin/passwd / / permission to view "/ bin/passwd" file with a "s" (Note: this file is not available on centOS6, it is available on centOS7)

-rwsr-xr-x. 1 root root 27832 Jun 10 2014 / bin/passwd

[root@centos730g ~] #

[root@centos6 ~] # ls-ld / tmp / / check the permissions of the directory "/ tmp" itself and find that there is a t in it

Drwxrwxrwt. 20 root root 4096 Oct 11 13:42 / tmp

[root@centos6 ~] #

There are three special permissions on the Linux system: SUID SGID STICKY

(the concept of security context: it is actually the access mechanism for accessing files.

What is the access mechanism when a user or a process accesses a file? Whether a process can access a file depends on the application mechanism of the access rights of the user initiating the process to the file. The application mechanism is to first determine whether the user initiating the process is the owner of the accessed file. If so, the primary permission is applied, otherwise, it is checked whether the user initiating the process is a subordinate group of the accessed file. If so, the group permission is applied, otherwise other permissions are applied. )

Security context:

1. The process runs as a user; the process is the agent of the user who initiates the secondary process, so all operations are completed with the identity and privileges of this user

But have we ever imagined how the user will apply the permissions on the command when he runs the command for the first time? just now we have been talking about that if a user executes "ls", it is equivalent to the ls process, etc., when accessing / etc, it depends on the user who initiated the ls process. Whether it is the owner of this file or directory or not, but now there is a question, we access the file "ls", "ls" itself is a file, then we can run this ls command, which depends on what? In the past, we have been talking about the object accessed by this process, but the process itself, before it is executed, is also a file, so whether a user has permission to run this command or not depends on what? It depends on the permissions of the file itself and on whether the user has permission to execute the file or not.

Let's take a look at the permissions of the file "/ bin/ls":

[root@centos6~] # ls-l / bin/ls found that the "/ bin/ls" file permission is 755

-rwxr-xr-x.1 root root 109208 May 11 16:59 / bin/ls

[root@centos6~] #

Our current user is root, so when a root user runs this program directly, in whose capacity does he access it? We see that root is the owner of the file "/ bin/root", so run the owner's permissions

So now we have another user, the hadoop user.

[root@centos6 ~] # useradd hadoop

[root@centos6 ~] # su-hadoop

[hadoop@centos6 ~] $ls-l / bin/ls / / you can see that when a hadoop user looks at the ls command, he finds that the owner of the ls command is still the root user.

-rwxr-xr-x. 1 root root 117048 May 11 16:59/bin/ls

[hadoop@centos6 ~] $

Then the hadoop user, when executing the ls command, is executed with the permission of the other user in the ls command, "rmerx". But there is no write permission, so hadoop users cannot change this file.

So whether a user has permission to run a command depends on whether the user has permission to execute the file of the command.

The question is, who initiated this command as a process on behalf of the user?

Is a shell process, so any user who executes a process is a child of his shell process, and we can run the "pstree" command to see:

├─ sshd ─┬─ sshd ─── bash ─── su ─── bash ─── pstree, in whose capacity does shell run?

The answer is that whoever's shell runs as someone: use the "ps aux" command to know:

Hadoop 30540 0.0 108352 1776 pts/1 S 11:36 0:00-bash

We must remember that after each user logs in to the system, there is a default shell that runs as the current user.

So the process initiated by each user is first a child process of shell under the shell command, and then he can map the permissions of this file under the identity of the current user, and only if he has the right to execute can he run.

)

two。 Permission matching model:

(1) determine whether the owner of the process is the owner of the accessed file; if so, apply the owner's authority; otherwise, proceed to the second step

(2) determine whether the owner of the process belongs to the file group being accessed; if so, apply the permissions of the group; otherwise, proceed to step 3.

(3) apply the permission of other

(if the user running on the current system is "hadoop", in whose capacity is the ls process running when the hadoop user initiates the ls command? It is running as hadoop, which means that although the main group of the ls program file is the root user, and when the hadoop user initiates this command, it is the other user who can apply the permissions of the other user of the ls program file, but after the ls process is initiated, the hadoop user is the owner.

[hadoop@centos6 ~] $whoami

Hadoop

[hadoop@centos6 ~] $ls-l / bin/ls

-rwxr-xr-x. 1 root root 117048 May 11 16:59/bin/ls

[hadoop@centos6 ~] $

If a user initiates a process, then the process represents that the user is running, so this means that although the master group of the program file of the process is root, after the program is started by the user, it becomes a process, and the owner of the process is the current user.)

SUID:

By default: a process initiated by a user whose owner is its initiator; therefore, it runs as the initiator.

[hadoop@centos6 ~] $ps aux / / you can see that the initiator of bash is a hadoop user

Hadoop 30540 0.0 108352 1776 pts/1 S 11:36 0:00-bash

[hadoop@centos6] $ls-l / bin/bash / / bash program file owner, group is root

-rwxr-xr-x. 1 root root 941880 May 11 07:21/bin/bash

[hadoop@centos6 ~] $

Therefore, we must understand that the master group of the program file is different from the master group of the process after the program runs.

After the program starts, it becomes a process, and the process has nothing to do with the program file.

The owner of the process is the initiator of the process, and the owner can initiate the process as long as he has the right to execute the program file.

The above is a normal rule, but with SUID, this rule has been changed.

When initiating this process, if a file has SUID permission, it means that the operator of the process is not the initiator, but the owner of the file itself.

The functions of SUID:

When a user runs a program, if the program has SUID permission, when the program runs as a process, the owner is not the initiator, but the owner of the program file itself.

What does this mean?

For example, if bash has SUID, after each user logs in, the open bash runs as root, so that any user can pretend to be a root user.)

Give an example to demonstrate:

[hadoop@centos6 ~] $ls-l / bin/cat / / View the master group of the original cat program is root, and other users have permission to execute.

-rwxr-xr-x. 1 root root 48568 May 11 16:59/bin/cat

[hadoop@centos6 ~] $ls-l / etc/shadow / / View the permissions of the file shadow. You can see that there is no permission for any user. In fact, the absence of any permissions will not work for the root administrator, but it will work for ordinary users, who are not allowed to view the contents of the file.

-. 1 root root 1089 Nov 4 11:36 / etc/shadow

[hadoop@centos6 ~] $cat / etc/shadow / / ordinary users hadoop users run cat programs to view shadow files, but shadow file permissions are not allowed for ordinary users, so they are prohibited

Cat: / etc/shadow: Permission denied

[root@centos6 ~] # cp / bin/cat / tmp/ program files do not have to be saved in the / bin/ directory

[root@centos6] # chmod cat / tmp/cat / / We add SUID to the cat program so that when the cat sequence is initiated by an ordinary user, he runs as the owner of his program file, root.

[hadoop@centos6 ~] $ls-l / tmp/cat / / look at the cat command again and find that there is a SUID function

-rwsr-xr-x. 1 hadoop hadoop 48568 Nov 4 15:26 / tmp/cat

[hadoop@centos6 ~] $/ tmp/cat / etc/shadow / / when you view the shadow file again, it runs as root, so you can see the contents of the file.

Root:$6 $OVD4n2P9EgnrtYnm$WDc9Jap/CVzJe8rTmHSPjgSvPz6o5JlzmcqftQv9wvPJd8lGkyZv43rG876rsYYngDXH6Ke3zBYn5SrzBZc/j.:17085:0:99999:7:::

Bin:*:15980:0:99999:7:::

Daemon:*:15980:0:99999:7:::

Adm:*:15980:0:99999:7:::

Lp:*:15980:0:99999:7:::

Sync:*:15980:0:99999:7:::

Shutdown:*:15980:0:99999:7:::

Halt:*:15980:0:99999:7:::

Mail:*:15980:0:99999:7:::

[hadoop@centos6 ~] $whoami / / but our current user is still hadoop

Hadoop

[hadoop@centos6 ~] $

The above demonstration verifies the function of SUID, that is, when a user wants to run a program, if the program has SUID function, then when the program is initiated as a process, the owner of the process is no longer the initiator, but the owner of the program file.

The function of SUID is reflected in that we ordinary users can change their own passwords. Because when the user runs the passwd program and initiates it as a process, because passwd has SUID function, then after running, the owner of passwd is root, so the password can be changed. And save the password in the / etc/shadow file.

[root@centos7 ~] # ls-l / bin/passwd

-rwsr-xr-x. 1 root root 27832 Jun 10 2014 / bin/passwd

[root@centos7 ~] #

As a result, we find that SUID is risky.

Manage SUID permissions for files:

Chmod u + |-s FILE.

Display location (that is, where the SUID symbol S appears): the executive permission bit of the owner

If the owner originally has the permission to execute, it is displayed as lowercase s

Otherwise, display as uppercase S

SGID:

SGID is generally used to change the group permissions of a directory.

Give an example to demonstrate:

[root@centos6 ~] # useradd fedora

[root@centos6 ~] # useradd mygrp

[root@centos6 ~] # useradd centos

[root@centos6 ~] # usermod-a-G mygrp fedora / / add additional groups to fedora users

[root@centos6 ~] # usermod-a-G mygrp centos / / add additional groups to centos users

[root@centos6 ~] # id fedora

Uid=501 (fedora) gid=501 (fedora) groups=501 (fedora), 502 (mygrp)

[root@centos6 ~] # id centos

Uid=504 (centos) gid=504 (centos) groups=504 (centos), 502 (mygrp)

[root@centos6 ~] # mkdir / var/tmp/test

[root@centos6~] # chown: mygrp / var/tmp/test / / change the directory's subordinate group to "mygrp"

[root@centos6~] # ls-dl / var/tmp/test/

Drwxr-xr-x. 2 root mygrp 4096 Nov 4 19:36 / var/tmp/test/

[root@centos6 ~] # chmod Grouw / var/tmp/test/ add write permissions to the group belonging to the user

[root@centos6 ~] # ls-dl / var/tmp/test/

Drwxrwxr-x. 2 root mygrp 4096 Nov 4 19:36 / var/tmp/test/

[root@centos6 ~] # su-fedora / / switch users and let fedora users put a file on the bed frame in the directory

[fedora@centos6 ~] $cd / var/tmp/test/

[fedora@centos6 test] $touch a.fedora

[fedora@centos6 test] $ls-l / / see the owner of the file created by the fedora user in the directory, and the group is all fedora

Total 0

-rw-rw-r--. 1 fedora fedora 0 Nov 4 19:39 a.fedora

[fedora@centos6test] $exit

Logout

[root@centos6 ~] # su-centos / / switch to the centos user and create a file in the directory

[centos@centos6 ~] $touch a.centos

[centos@centos6 ~] $ls-l

Total 0

-rw-rw-r--. 1 centos centos 0 Nov 4 19:39 a.centos

[centos@centos6 ~] $cd / var/tmp/test/

[centos@centos6 test] $touch a.centos

[centos@centos6 test] $ls-l / / centos the main group of files created in the directory is also centos itself

Total 0

-rw-rw-r--. 1 centos centos 0 Nov 4 19:40 a.centos

-rw-rw-r--. 1 fedora fedora 0 Nov 4 19:39 a.fedora

[centos@centos6 test] $

Combine the above steps to practice the effect of SGID:

[centos@centos6 test] $exit

Logout

[root@centos6 ~] # chmod genders / var/tmp/test/ add SGID function to the directory in the administrator environment

[root@centos6 ~] # ls-ld / var/tmp/test/ View the changes in permissions after adding SGID to the directory

Drwxrwsr-x. 2 root mygrp 4096 Nov 4 19:40 / var/tmp/test/

[root@centos6 ~] # su-fedora / / switch to the fedora user again, and once again a file is common in the directory. At this time, the subordinate group of the file is no longer the user itself, but the subordinate group of the directory.

[fedora@centos6 ~] $cd / var/tmp/test/

[fedora@centos6 test] $touch b.fedora

[fedora@centos6 test] $exit

Logout

[root@centos6 ~] # su-centos / / switch to the centos user and create a file in the directory entry. It is found that the subordinate group of the file has also become a subordinate group of the directory.

[centos@centos6 ~] $cd / var/tmp/test/

[centos@centos6 test] $touch b.centos

[centos@centos6 test] $ll

Total 0

-rw-rw-r--. 1 centos centos 0 Nov 4 19:40 a.centos

-rw-rw-r--. 1 fedora fedora 0 Nov 4 19:39 a.fedora

-rw-rw-r--. 1 centos mygrp 0 Nov 4 19:54 b.centos

-rw-rw-r--. 1 fedora mygrp 0 Nov 4 19:53 b.fedora

[centos@centos6 test] $

Any user who creates a file in this directory creates a file whose subordinate group is no longer the user's primary group or basic group, but a subordinate group of this directory, which is both SGID

The role of SGID:

If multiple users belong to the same group, and everyone has such a group in each other's subordinate group, and all have write access to this common subordinate group, so that the files created by each user can be modified by each other in the future, so the result he can bring is the files created by everyone, which can be changed by others in this directory.

(then someone said, "Why bother? I just let other users have write permission. In fact, this is not advisable. It is a very dangerous operation to let other users have write permission. But as an ordinary user, how to share your files with others so that others can write?" Think that there is no permission to belong to the main group, there is no other way but to modify permissions, so as administrators, in order to enable several development programmers in this group to modify each other's program files, we do it in this way. )

Problems caused by SGID

In such a directory, users can modify files created by other users, not only to modify, but also to delete all files in this directory, because the user has write permission in this directory.

In order to avoid users being able to delete files in this directory at will, Sticky is introduced.

Sticky is what we call the sticky bit.

What is the sticky position?

We can do a verification, that is, we delete the file based on another user name to see if we can delete it.

Demonstrate the operation:

[centos@centos6 test] $whoami

Centos

[centos@centos6 test] $rm a.fedora

Rm: remove write-protected regular emptyfile `a.fedora? Y

[centos@centos6 test] $ll

Total 0

-rw-rw-r--. 1 centos centos 0 Nov 4 19:40 a.centos

-rw-rw-r--. 1 centos mygrp 0 Nov 4 19:54 b.centos

-rw-rw-r--. 1 fedora mygrp 0 Nov 4 19:53 b.fedora

[centos@centos6 test] $

[centos@centos6 test] $exit

Logout

[root@centos6 ~] # su-fedora

[fedora@centos6 ~] $cd / var/tmp/test/

[fedora@centos6 test] $rm a.centos

Rm: remove write-protected regular emptyfile `a.centoskeeper? Y

[fedora@centos6 test] $ll

Total 0

-rw-rw-r--. 1 centos mygrp 0 Nov 4 19:54 b.centos

-rw-rw-r--. 1 fedora mygrp 0 Nov 4 19:53 b.fedora

[fedora@centos6 test] $exit

Logout

[root@centos6 ~] #

(in this way, since we can delete files created by other users in the changed directory at will, when a user creates a file, we delete the file, we say that the user did not create the file, because we deleted the file.

So to avoid such a problem, we just used "Sticky")

The demonstration is as follows:

[root@centos6] # chmod ovalt / var/tmp/test/ We have introduced that Sticky is "ovalt" to process the directory

[root@centos6 ~] # ls-ld / var/tmp/test/

Drwxrwsr-t. 2 root mygrp 4096 Nov 4 20:24 / var/tmp/test/

[root@centos6 ~] # su-fedora / / We switch users again. According to reason, both fedora and centos users and this directory belong to the same group, and the affiliated group of this directory has write permission, so these two users can create files and delete files in this directory.

[fedora@centos6 ~] $cd / var/tmp/test/

[fedora@centos6 test] $ll

Total 0

-rw-rw-r--. 1 centos mygrp 0 Nov 4 19:54 b.centos

-rw-rw-r--. 1 fedora mygrp 0 Nov 4 19:53 b.fedora

[fedora@centos6 test] $vim b.fedora / / Edit your own file and add "hello China" content

[fedora@centos6 test] $cat b.fedora

Hello China

[fedora@centos6 test] $vim b.centos / / Edit the centos user's file and successfully add "hellopeople"

[fedora@centos6 test] $cat b.centos

Hello people

[fedora@centos6 test] $

[fedora@centos6 test] $rm-f b.centos / / but with the addition of Sticky, users in the directory cannot delete files created by other users in this directory, but can create and delete their own files.

Rm: cannot remove `b.centoskeeper: Operation notpermitted

[fedora@centos6 test] $

[fedora@centos6 test] $rm-f b.fedora / / users can delete files created by themselves

[fedora@centos6 test] $ll

Total 0

-rw-rw-r--. 1 centos mygrp 0 Nov 4 19:54 b.centos

[fedora@centos6 test] $

[fedora@centos6 test] $touch b.fedora / / can also create files

[fedora@centos6 test] $ll

Total 0

-rw-rw-r--. 1 centos mygrp 0 Nov 4 19:54 b.centos

-rw-rw-r--. 1 fedora mygrp 0 Nov 4 20:40 b.fedora

[fedora@centos6 test] $

To sum up, the above demonstration is:

Generally speaking, as long as a directory uses t permission, anyone who has write permission in this directory can create files and modify their own files and other users' files, but when deleting them, they can only delete their own files or directories. You can't delete anyone else's.

Function: when a directory belongs to a group that has write permission and SGID permission, then all the subordinate groups that belong to this directory and create a new file or directory in this directory as a subordinate group, the subordinate group of the new file is not the basic group of the user, but the subordinate group of this directory.

Manage SGID permissions for files:

Chmod g+ |-s FILE.

Display location: the execution permission bit of the group

If the group originally has the permission to execute, it is displayed as lowercase s

Otherwise, display as uppercase S

Demo examples:

Main functions of SGID: modify the group permissions of the directory:

Sticky:

Function: for a group or globally writable directory, all users in the group or all users on the system can create new files or delete all existing files if they exist in this directory; if Sticky permission is set for such directories, each user can create new files and can only delete their own files

Manage Sticky permissions for files:

Chmod o + |-t FILE.

Display location: the execution permission bit of other users

Display as lowercase t if the other user originally has execute permission

Otherwise, display as uppercase T

The / tmp and / var/tmp directories on the system have Sticky permissions by default

[fedora@centos6 test] $ls-ld / tmp

Drwxrwxrwt. 11 root root 4096 Nov 4 20:51 / tmp

[fedora@centos6 test] $ls-ld / var/tmp

Drwxrwxrwt. 3 root root 4096 Nov 4 19:36 / var/tmp

[fedora@centos6 test] $

Another way to manage special permissions:

SUID SGID STICKY can also be combined into a three-digit permission, representing the owner (u), the group (g), and other users (o).

SUID SGID STICKY is converted to octal corresponding to

0 0 0

0 0 1 1

0 1 0 2

0 1 1 3

1 0 0 4

1 0 1 5

1 1 0 6

1 1 1 7

When weighting based on octal mode, you can add an octal number to the left of the default three-digit octal number

Chmod 1777: the 1 on the left represents the Sticky permission bit

This is why umask has four digits, and the leftmost permission bit represents the special permission bit.

[root@centos6~] # umask

0022 / / and the leftmost number 0 is not subtracted by 7, 7-0-7; this 0 indicates that the special permission is not enabled.

So we ignore the leftmost special permissions when using umask.

Facl: (uncritical content, just understand it)

File access control lists: file access control list

Facl is an additional weighting mechanism for files

Additional empowerment mechanisms can be implemented for specified users or groups

Function: every user has no way to modify the master group of any file, so as an ordinary user, I want to modify my own file and let others have write permission, so that others can write. What should we do then? At this time, we have no other way except to modify the permissions of other, but if we modify the permissions of other users of our file, it will be very dangerous, because we have changed the permissions of other users to read, then other users can read, this risk is not very great, but if we change the file of other users can execute, then other users can execute, then it is very dangerous, especially writable, then how to do? This adds a facl.

Getfacl command: / / View the list of weights

Getfacl FILE.

User:USERNAME:MODE / / indicates the permissions of additional users (if we authorize multiple users, the users here appear multiple times; if USERNAME is empty, it represents the permissions of the owner of the file,)

Group:GROUPNAME:MODE / / indicates the permission of the extra group (here, if GROUPNAME is empty, it is the permission that belongs to the group by default)

Setfacl: command / / set the weighting list

Empower the user:

Setfacl-m u:USERNAME:MODE FILE. / / empowered users

Empower the group:

Setfacl-m g:GROUPNAME:MODE FILE. / / empowered user groups

Revoke the entitlement:

Setfacl-x u:USERNAME FILE....

Setfacl-x g:GROUPNAME FILE.

The purpose of facl is to:

You can allow each user to modify the permissions of their own files, but this kind of permission is not to modify the permissions of the default ujournal gpeno, but to add an additional permission mechanism, so facl is an additional weighting mechanism for files.

Facl is an additional weighting mechanism for files:

Additional empowerment mechanism:

It can be implemented for specified users and groups, such as an ordinary user. We can make it clear that my file can be accessed by another user, but it should not be owned here. It's just an additional one who has what access rights.

This means that in addition to the original uquoise gpeno, another layer allows ordinary users to control the weighting mechanism that empowers other users or groups.

For example:

[root@centos6tmp] # su-centos

[centos@centos6 ~] $cd / tmp

[centos@centos6 tmp] $touch test.centos

[centos@centos6 tmp] $ls-l

Total 0

-rw-rw-r--. 1 centos centos 0 Nov 4 22:54 test.centos

[centos@centos6 tmp] $exit

Logout

[root@centos6 tmp] # su-fedora

[fedora@centos6 ~] $echo hello > / tmp/test.centos / / found no permission to write

-bash: / tmp/test.centos: Permission denied

[fedora@centos6~] $getfacl / tmp/test.centos / / View the user's permissions

Getfacl: Removing leading'/ 'from absolutepath names

# file: tmp/test.centos

# owner: centos / / owner

# group: centos / / Group

User::rw- / / owner's permissions, and you can see that there are no additional users

Group::rw- / / belongs to the group's permissions, and you can see that there are no additional users

Other::r-- / / other users

[fedora@centos6 ~] $exit

Logout

[root@centos6 tmp] # su-centos

[centos@centos6 ~] $setfacl-m u:fedora:rw / tmp/test.centos / / add permissions to specified users using access control lists

[centos@centos6 ~] $getfacl / tmp/test.centos / / View the additional permissions added to this file

Getfacl: Removing leading'/ 'from absolutepath names

# file: tmp/test.centos

# owner: centos / / owner

# group: centos / / Primary Group

User::rw- / / authority of the owner

User:fedora:rw- / / A new additional sovereign restriction column is added, and the owner is fedora, and the permission rw

Group::rw-

Mask::rw-

Other::r--

[centos@centos6 ~] $exit

Logout

[root@centos6 tmp] # su-fedora

[fedora@centos6 ~] $echo hello > / tmp/test.centos / / can be written.

[fedora@centos6 ~] $getfacl / tmp/test.centos / / when viewing additional permissions, the file is written as an absolute path

Getfacl:Removing leading'/ 'from absolute path names

# file: tmp/test.centos

# owner: centos

# group: centos

User::rw-

User:fedora:rw-

Group::rw-

Mask::rw-

Other::r--

[fedora@centos6 ~] $cd / tmp

[fedora@centos6 tmp] the $getfacl test.centos / / file is written as a relative path, so there is no hint in the column of faces.

# file: test.centos

# owner: centos

# group: centos

User::rw-

User:fedora:rw-

Group::rw-

Mask::rw-

Other::r--

[fedora@centos6 tmp] $cat test.centos

Hello

[fedora@centos6 tmp] $ll test.centos / / for files with additional rights, when viewing details, there is a plus sign at the end of the previous permission limit, which indicates that the list of additional permissions has been added successfully

-rw-rw-r--+ 1 centos centos 6 Nov 4 23:03 test.centos

[fedora@centos6 tmp] $

[centos@centos6~] $setfacl-m g:mygrp:rw/tmp/test.centos / / set additional group permissions for the directory

[centos@centos6 ~] $getfacl / tmp/test.centos / / additional permissions to view directories

Getfacl: Removing leading'/ 'from absolutepath names

# file: tmp/test.centos

# owner: centos

# group: centos

User::rw-

User:fedora:rw-

Group::rw-

Group:mygrp:rw- / / added an extra group permission

Mask::rw-

Other::r--

[centos@centos6 ~] $

The above is our access control list mechanism, but once we have the access control list, our permission application model has changed. the security context we used to talk about before is that when a process accesses a file, first check whether the owner of the process is the owner of the file, or run the owner's permission, otherwise check whether the subordinate group of the process is a file group, or run the subordinate group. Otherwise, run the permissions of other users

But with the access control list, when a user-initiated process accesses a file, it first checks whether the process owner is the owner of the accessed file, and runs the master permission. Otherwise, check whether there is an additional process access control list specifically defined for the user on this file, and if so, apply the permission of this specific access control list. Otherwise, if you are checking whether the process tree group is a member of the accessed file, run the permissions of the group, otherwise check whether the group to which the user belongs has a special access control list, and if so, apply the permission of this access control list, otherwise apply other permissions.

The above example demonstrates:

Verify the order of the security context after you have the access control list:

[centos@centos6 ~] $exit

Logout

[root@centos6 ~] # useradd hadoop / / add a new user, and then use this user to view the file to verify whether you can view the contents of the file when the access control list is not set for hadoop.

[root@centos6 ~] # su-hadoop

[hadoop@centos6 ~] $getfacl / tmp/test.centos / / View file access control list. No control is set on hadoop. Hadoop executes other permissions on this file according to the order of the security context.

Getfacl: Removing leading'/ 'from absolutepath names

# file: tmp/test.centos

# owner: centos

# group: centos

User::rw-

User:fedora:rw-

Group::rw-

Group:mygrp:rw-

Mask::rw-

Other::r--

[hadoop@centos6 ~] $cat / tmp/test.centos / / can indeed view the contents of the file

Hello

[hadoop@centos6 ~] $exit

Logout

[root@centos6 ~] # setfacl-mu hadoop set access control list

[hadoop@centos6 ~] $getfacl / tmp/test.centos / / View the access control list of the file

Getfacl: Removing leading'/ 'from absolutepath names

# file: tmp/test.centos

# owner: centos

# group: centos

User::rw-

User:fedora:rw-

User:hadoop:--- / / with the access control column of hadoop

Group::rw-

Group:mygrp:rw-

Mask::rw-

Other::r--

[root@centos6~] # su-hadoop

[hadoop@centos6 ~] $cat / tmp/test.centos / / does not have permission to view the contents of the file now.

Cat: / tmp/test.centos: Permission denied

[hadoop@centos6 ~] $

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.