Linux permission and ownership model

One user and one group

Let's take a look at the Linux permission and ownership model. We can see that each file belongs to a user and a group. This is the core of the permission model in Linux. You can view users and groups in the LS-l list:

$ ls -l /bin/bash

-Rwxr-XR-x 1 root wheel 430540 Dec 23/bin/bash in this special example, the/bin/bash Executable File belongs to the root user, and in the wheel group. The Linux permission model allows three independent permission levels for each file system object-they are the file owner, the file group, and all other users.

Understanding "ls-l"

Let's take a look at our LS-L output and check the first column of this list:

$ LS-L/bin/bash-rwxr-XR-x 1 root wheel 430540 Dec 23/bin/bash the first field-rwxr-XR-X contains permissions for this special file. The first character (-) in this field specifies the file type. In this example, it is a regular file. Other possible first characters include:

"D" directory "L" Symbolic Link "C" character dedicated device file "B" block dedicated device file "p" first-in-first-out "S" socket three triplet $ LS-L/ bin/bash-rwxr-XR-x 1 root wheel 430540 Dec 23/bin/bash the rest of this field consists of three triple characters. The first three-character group represents the permissions of the file owner, the second represents the permissions of the file group, and the third represents the permissions of all other users:

"Rwx" "R-X" "R-X" above, r indicates that read is allowed (View data in the file), w indicates that write is allowed (modify and delete files ), X indicates that "execution" is allowed ). By putting all this information together, we can find that everyone can read and execute the file, but only the file owner (Root User) can modify the file in any way. Therefore, although you can copy the file, only the root user is allowed to update or delete it.

Who am I? Before learning how to change the user ownership and group ownership of a file, let's first take a look at how to know your current user identity and membership. Unless you have recently used the su command, your current user ID is the user ID you use to log on to the system. However, if you use su frequently, you may not remember your current valid user ID. To view the user ID, enter whoami: # whoamiroot # su drobbins $ whoamidrobbins in which group do I belong? To see which group you belong to, run the Group Command $ groupsdrobbins wheel audio. In the preceding example, I am a member of the drobbins, wheel, and audio groups. If you want to see the groups of other users, specify their usernames as parameters:

$ Groups root daemonroot: Root bin daemon sys ADM Disk Wheel floppy dialout tape videodaemon: Daemon bin ADM changes user and group ownership in order to change the owner or group of files or other file system objects, use chown or chgrp respectively. Both commands require one user name or group name as the parameter, followed by one or more file names.

# Chown root/etc/passwd # chgrp wheel/etc/passwd you can also use another form of CHOWN command to set the owner and group at the same time:

# Chown root. Wheel/etc/passwd unless you are a super user, you cannot use chown. However, anyone can use chgrp to change the group ownership of files to the group they belong.

Recursive ownership changes both chown and chgrp have a-r option that can be used to recursively apply ownership and group changes to the entire directory tree. For example: # chown-r drobbins/home/drobbins introduction chmodchown and chgrp can be used to change the owner and group of File System Objects, another program called chmod is used to change the rwx permission we can see in the LS-l list. Chmod has two or more parameters: "Mode", which describes how to change permissions, followed by the list of files or files that will be affected: $ chmod + x scriptfile. SH in the above example, our "Mode" Is + X. As you may guess, the + x mode tells chmod that the special file is executable to users, groups, and anyone else. If we want to remove all the execution permissions for a file, we should do this: $ chmod-x scriptfile. sh user/group/other granularity up to this point, our chmod example has affected all three triplet-users, groups and all other users. Generally, it is convenient to modify only one or two three tuples at a time. To do this, you only need to specify the symbol character for the specific triple that you want to modify before the + or-symbol. Use U for the "user" triple, G for the "Group" triple, and O: $ chmod go-W scriptfile for "Others/everyone. sh we just removed the write permissions of the group and all other users, but kept the "owner" permission unchanged. In addition to opening and disabling permission slots, You can reset the permissions together. By using the = Operator, we can tell chmod that we want to specify the permission and cancel other permissions: $ chmod = RX scriptfile. sh above, we only set all the "read" and "execute" bits, but not all the "write" bits. If you only want to reset a specific triple, you can specify the symbol name of the triple before = as follows:

$ chmod u=rx scriptfile.sh

Digital Mode

Until now, we have used the mode called "symbol" to specify the permission change with CHMOD. However, there is also a common method to specify permissions-to use four octal digits. Use a syntax called the number permission syntax. Each digit represents a permission triple. For example, in section 1777, section 777 sets the "owner", "group", and "other" Logos we discuss in this chapter. 1 is used to set a special permission bit. We will discuss it at the end of this chapter. This chart illustrates how to explain the second to fourth places (777 ):

Mode Number

rwx 7 　　rw- 6 　　r-x 5 　　r-- 4 　　-wx 3 　　-w- 2 　　--x 1 　　--- 0

Numeric permission syntax

When you need to specify ownership for a file, the numeric permission syntax is particularly useful, for example, in the following example:

$ chmod 0755 scriptfile.sh 　　 　　$ ls -l scriptfile.sh 　　 　　-rwxr-xr-x　　1 drobbins drobbins　　　　 0 Jan　9 17:44 scriptfile.sh

In this example, we use the 0755 mode, which expands to set "-rwxr-XR-X" for a complete permission ".

Umask

When a process creates a new file, it specifies the permissions that the new file should have. Generally, the requested mode is 0666 (everyone can read and write), which has more permissions than we want. Fortunately, no matter when a new file is created, Linux will refer to what is called "umask. The system uses the umask value to reduce the initial permission to a more reasonable and safer permission. You can enter umask in the command line to view your current umask settings:

$ umask 　　 　　0022

In Linux, the default value of umask is generally 0022, which allows others to read your new files (if they can get them) but cannot be modified. To make the new file more secure by default, you can change the umask settings: $ umask 0077 umask will ensure that the Group and other users have no permissions for the new file. How does umask work? Unlike the "General" permission of a file, umask specifies which permission should be disabled. Let's take a look at our "Mode-to-number" ing table so that we can understand what umask 0077 means: the pattern number rwx 7 RW-6 r-x 5 r -- 4-WX 3-w-2 -- X 1 --- 0 uses this table, and the last three digits of 0077 are extended to --- rwxrwx. Now, remember that umask tells the system which permission to disable. We can infer that all the "Group" and "other" permissions will be disabled, and the "user" permissions will not be retained.

Introduction to SUID and SGID

When you first log on, a new shell process is started. You already know, but you may not know that this new shell process (usually bash) runs with your user identity. In this way, the bash program can access all your files and directories. In fact, as users, we rely entirely on other programs to represent our operations. Because the programs you start inherit your user identity, they cannot access any file system objects that you are not allowed to access.

For example, you cannot directly modify the passwd file because the "write" mark has been disabled for each user except the "Root User:

$ ls -l /etc/passwd 　　 　　-rw-r--r--　　1 root　　 wheel　　　　 1355 Nov　1 21:16 /etc/passwd

However, general users do need to be able to modify/etc/passwd (at least indirectly) whenever they need to change their passwords ). However, if the user cannot modify the file, how can this work be completed?

SUID

Fortunately, the Linux permission model has two special bits: "SUID" and "SGID ". When the "SUID" of an executable program is set, it will run on behalf of the owner of the executable file, rather than on behalf of the person who started the program. Now, go back to the/etc/passwd issue. If you look at the passwd executable file, we can see that it belongs to the root user:

$ ls -l /usr/bin/passwd 　　 　　-rwsr-xr-x　　1 root　　 wheel　　　 17588 Sep 24 00:53 /usr/bin/passwd

You will also notice that here there is a s that replaces an X in the user permission triple. This indicates that SUID and executable bit are set for this special program. For this reason, when passwd is run, it indicates that the root user executes (with full superuser access), rather than the user that runs it. Because passwd runs with root user access, it is okay to modify the/etc/passwd file.

SUID/SGID warning description

We can see how SUID works, and SGID works in the same way. It allows the program to inherit the group ownership of the program, rather than the program ownership of the current user. Here are some other but important information about SUID and SGID. First, SUID and SGID occupy the same space as X in the LS-l list. If the x bit is set, the corresponding bit is represented as S (lower case ). However, if no X-bit is set, it indicates S (uppercase ). Another important note: In many environments, SUID and SUID are useful, but improper use of these bits may compromise system security. It is best to use the "SUID" program as little as possible. The passwd command is one of the few commands that must use "SUID.

Change SUID and SGID

Setting and removing SUID and SGID bits is quite simple. Here, we set the SUID bit:

# chmod u+s /usr/bin/myapp

Here, we remove the sgid bit from a directory. We will see how the sgid bit affects the directories on the following screens:

# chmod g-s /home/drobbins

So far, we can view the permissions from the perspective of regular files. When you look at permission limits from a directory perspective, the situation is a little different. Directories use the same permission flag, but they are interpreted as representing slightly different meanings. If the "read" flag is set for a directory, you can list the contents of the directory. "Write" indicates that you can create files in the directory, "execute" indicates that you can access this directory and access any internal subdirectories. Without the "execute" flag, the file system objects in the directory are not accessible. Without the "read" flag, the file system objects in the directory cannot be viewed, but the objects in the directory can still be accessed as long as someone knows the complete path of the objects on the disk. Directory and SGID if the "SGID" flag of the directory is enabled, any file system objects created in the directory will inherit the directory group. This special feature is useful when you need to create a directory tree for a group of people in the same group. You only need to do this:

# mkdir /home/groupspace 　　 　　# chgrp mygroup /home/groupspace 　　 　　# chmod g+s /home/groupspace

Now, all users in the mygroup group can create files or directories in/home/GroupSpace. Similarly, they will automatically assign group ownership to the mygroup. According to the user's umask settings, the new file system object can or cannot be readable, writable, or executable for other members of the mygroup group. By default, Linux directories are represented in a way that is not ideal in all situations. Generally, anyone who has write access to a directory can rename or delete files in the directory. This behavior is reasonable for the categories used by individual users. However, for directories used by many users, especially/tmp and/var/tmp, this behavior may be troublesome. Anyone can write these directories, and anyone can delete or rename any other person's files-even if they do not belong to them! Obviously, it is difficult to use/tmp for any meaningful file when any other user can input "RM-RF/tmp/*" at any time and corrupt everyone's file. Fortunately, Linux has something called Sticky Bit. When a sticky bit (chmod + T) is set for/tmp, the only object that can be deleted or renamed in/tmp is the owner of the directory (usually root user), file owner or root user. In fact, by default, the/tmp sticky bits are enabled for all Linux distribution packages, and you can also find that sticky bits are useful in other situations.