Linux Permissions detailed __linux

A user, a group
Let's take a look at Linux permissions and ownership models. We've seen each file belong to a user and a group. This is the core of the permissions 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 18:27/bin/bash
In this particular example, the/bin/bash executable belongs to the root user and is in the wheel group. The Linux permissions model works by allowing three separate permission levels to be set for each filesystem object-they are the owner of the file, the group of files, and all other users.

Understanding "Ls-l"

Let's take a look at our ls-l output and check the first column of the list:

$ ls-l/bin/bash
-rwxr-xr-x 1 root wheel 430540 Dec 18:27/bin/bash
The first field-rwxr-xr-x the symbolic representation of the permission that contains the special file. The first character (-) in the field specifies the type of the file, which in this case is a regular file. Other possible first characters are:
"D" Directory
"L" symbolic link
"C" character special device file
"B" block specialized equipment files
"P" Advanced first Out
"S" sockets
Three ternary groups
$ ls-l/bin/bash
-rwxr-xr-x 1 root wheel 430540 Dec 18:27/bin/bash
The remainder of the field consists of three ternary characters. The first ternary character group represents the permissions of the file owner, the second represents the permissions for the file's group, and the third represents the permissions of all other users:
"Rwx"
"R-x"
"R-x"
Above, r indicates permission to read (view the data in the file), W indicates permission to write (modify file and delete), and X indicates allow "Execute" (Run program). With all this information together, we can see that everyone can read the contents of the file and execute the file, but only the file owner (root) can modify the file in any way. Therefore, although a typical user can copy the file, only the root user is allowed to update or delete it.
Who am I.
Before we look at how to change the user ownership and group ownership of a file, let's first look at how you know your current user identity and membership. Unless you have recently used the SU command, your current user ID is the identity of the user you use to log on to the system. However, if you use SU frequently, you may not remember your currently valid user identity. To view the user ID, enter WhoAmI:
# WhoAmI
Root
# su Drobbins
$ whoami
Drobbins
Which group I was in.
To see which group you belong to, use Group command:
$ groups
Drobbins Wheel Audio
In the example above, I am a member of the Drobbins, wheel, and audio groups. If you want to see what group other users are in, specify their username as an argument:
$ groups Root Daemon
Root:root bin Daemon Sys ADM disk wheel floppy dialout tape video
Daemon:daemon Bin ADM
change user and group ownership
To change the owner or group of files or other file system objects, use either Chown or Chgrp respectively. Both commands have a username or group name parameter followed by one or more file names.

# chown ROOT/ETC/PASSWD
# CHGRP WHEEL/ETC/PASSWD
You can also set both owners and groups in another form of the Chown command:
# chown ROOT.WHEEL/ETC/PASSWD
You cannot use chown unless you are superuser, but anyone can use CHGRP to change the group ownership of a file to the group they belong to.
Recursive ownership change
Both Chown and Chgrp have a-r option that can be used to tell them to recursively apply ownership and group changes to the entire directory tree. For example:
# Chown-r Drobbins/home/drobbins
Introduction chmod
Chown and CHGRP can be used to change the owners and groups of file system objects, while another program-called chmod--is used to change the RWX permissions that we see in the Ls-l list. Chmod with two or more parameters: "Mode", which describes how to change permissions, followed by a list of files or files that will be affected:
$ chmod +x scriptfile.sh
In the example above, our "mode" is +x. As you might guess, the +x pattern tells Chmod to make the special file executable for users, groups, and anyone else. If we want to remove all execution permissions for a file, we should do this:
$ chmod-x scriptfile.sh
User/group/other granularity
By this, our chmod example has affected all three triples-users, groups, and all other users. In general, it is convenient to modify only one or two triples at a time. To do this, simply specify the symbol characters for the specific triples you want to modify before the + or-symbol. For the "users" triple Group use U, for "group" ternary group using G, for "other/Everyone" use O:
$ chmod go-w scriptfile.sh
We have just dropped the write permission for the group and all other users, leaving the owner permission fixed.
Re-set permissions
In addition to alternating open and close permission bits, we can reset them together. By using the = operator, we can tell chmod that we want to specify permissions and remove other permissions:
$ chmod =rx scriptfile.sh
Above, we only set all the "read" and "execute" bit, not all the "write" bit. If you just want to reset a specific ternary group, you can specify the symbol name for the ternary group as follows:
$ chmod U=rx scriptfile.sh
Digital mode
Until now, we have used a pattern called "symbol" to specify a change in permissions using Chmod. However, the specified permission also has
A commonly used method-use a 4-digit octal number. Using syntax called numeric permission syntax, each one represents a permission
Ternary group. For example, in 1777, 777 sets the "owner", "group", and "other" we discussed in this chapter
Sign. 1 is used to set up a specific permission bit, which we will discuss at the end of this chapter. This chart shows how to explain the second to
Four-bit (777):
Pattern number
RWX 7
Rw-6
R-x 5
r--4
-WX 3
-w-2
--x 1
---0

Digital Permissions Syntax
The numeric permission syntax is especially useful when you need to specify all permissions for a file, such as in the following example:
$ chmod 0755 scriptfile.sh
$ ls-l scriptfile.sh
-rwxr-xr-x 1 drobbins drobbins 0 9 17:44 scriptfile.sh
In this example, we used the 0755 pattern, 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. Typically, the requested pattern is 0666 (everyone can read and write), and it has more permissions than we want. Fortunately, whenever a new file is created, Linux will refer to something called "umask". The system uses the Umask value to reduce the initially specified permissions to a more reasonable and secure permission. You can view your current umask settings by entering Umask on the command line:
$ umask
0022
On Linux systems, the default value of Umask is typically 0022, which allows others to read your new files (if they can get them), but cannot modify them. To make new files more secure by default, you can change the Umask setting: $ umask 0077umask will ensure that groups and other users have absolutely no permissions on newly created files. So, how does umask work? Unlike the general permissions of a file, umask specifies which permissions should be turned off. Let's look at our "pattern to number" map so that we can understand what the 0077 umask mean: The pattern number rwx 7 rw-6 r-x 5 r--4-wx 3-w-2--x 1---0 use the table, and 0077 the last three bit to expand Exhibition for---rwxrwx. Now, remember that Umask tells the system which permissions to disable. Based on the inference, we can see that all the groups and other permissions will be turned off, and the user right will remain fixed.
Introduction to Suid and Sgid
When you initially log on, a new shell process is started. You already know, but you may not yet know this new shell
The process (usually bash) runs with your user identity. In this way, the bash program can access all files that belong to you and
Directory. In fact, as a user, we rely entirely on other programs to perform operations on our behalf. Because the program you started inherits the
Your user identity, so they do not have access to any file system objects that you are not allowed to access.
For example, a general user cannot modify the passwd file directly because the "write" flag has been turned off for every user except "root":
$ ls-l/etc/passwd
-rw-r--r--1 root Wheel 1355 Nov 1 21:16/etc/passwd
However, the average user does need to be able to modify the/etc/passwd (at least indirectly) at any time they need to change their password. However, if the user cannot modify the file, how does this work?
Suid
Fortunately, the Linux permissions model has two dedicated bits, called "suid" and "Sgid". When you set the "Suid" of an executable program, it will run on behalf of the owner of the executables, not the person who started the program. Now, back to the/etc/passwd question. 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 00:53/usr/bin/passwd
You will also notice that there is an X in the triple group of user rights. This shows that for this particular program, the SUID and executable bits are set. For this reason, when passwd runs, it executes on behalf of the root user (with full superuser access), rather than on behalf of the user running it. And because passwd runs with root access, you can modify the/etc/passwd file without any problems.
Suid/sgid Warning Note
We see how SUID works, Sgid in the same way. It allows the program to inherit the group ownership of the program, rather than the current user's program ownership. Here are some other, but important, information about SUID and Sgid. First, suid and Sgid occupy the same space as the X-bits in the Ls-l list. If the x bit is also set, the corresponding bit is represented as s (lowercase). However, if no x bit is set, it is represented as S (uppercase). Another important tip: in many environments, suid and suid are useful, but improper use of these bits may compromise the security of the system. 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 fairly straightforward. Here we set the SUID bit:
# chmod U+s/usr/bin/myapp
Here, we remove the Sgid bit from a directory. We'll see how the SGID bit affects the directories in the following screens:
# chmod G-s/home/drobbins
Permissions and orders so far, we look at permissions from the perspective of regular files. When you look at permissions from a directory perspective, the situation is a little different. The directory uses the same permission flags, but they are interpreted as representing a slightly different meaning. For a directory, if the "read" flag is set, you can list the contents of the directory, and "write" indicates that you can create a file in the directory, and "execute" means that you can go to that directory and access any subdirectories within it. There is no "execute" flag, and file system objects within the directory are inaccessible. Without the "read" flag, the file system objects within the directory are not viewable, but as long as someone knows the full path of the objects on the disk, they can still access the objects within the directory. Directories and sgid Any file system objects created within the directory will inherit the group of directories if the "Sgid" flag for the directory is enabled. This particular feature works well when you need to create a directory tree that belongs to a group of people in the same group. You just have 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 within/home/groupspace, and likewise, he
They are also automatically assigned to MyGroup group ownership. Depending on the user's umask settings, the new file system object is
Other members of the MyGroup group can or may not be readable, writable, or executable.
Directories and Deletes
By default, the Linux directory behaves in a way that is not ideal in all cases. In general, just one
The directory has write access, and anyone can rename or delete the files in that directory. For a directory used by individual users, this line
For it is very reasonable.
However, this behavior can be problematic for directories used by many users, especially/TMP and/var/tmp.
Because anyone can write these directories, anyone can delete or rename any other person's files-even if it is not part of the
of theirs. Obviously, when any other user can enter "rm-rf/tmp/*" at any time and damage everyone's text
, it is difficult to use/TMP for any meaningful document.
Fortunately, Linux has something called a "sticky bit" (sticky bit). When a sticky bit is set for/tmp (with
chmod +t), the only person who can delete or rename a file in/TMP is the owner of the directory (usually root)
, the owner of the file, or the root user. In fact, all Linux distribution defaults enable the/tmp sticky bit,
And you can also find that sticky bits work in other situations as well.
Difficult to understand the first
Summing up this chapter, we'll take a final look at the incomprehensible first digits of the digital model. As you can see, this first digit
Used to set sticky, suid, and sgid bits:
Suid sgid Sticky mode number on "on" on "on" on "Off" on "off" 5 on "off" 4 Off "on" 3 Off "off" 2 Off "on" 1 off "off 0
Here's an example of how to set permissions on a directory in a 4-bit number mode, which will be used by a workgroup:
# chmod 1775/home/groupfiles
Please think about the meaning of the 1755 digital mode permission setting.