Terminal sessions and orphan Process Groups (POSIX-2.2.2.52)-explanations

The terminal issues involve several concepts, including process groups, sessions, and jobs. The following sections describe them respectively. A session contains a series of processes. These processes are organized into several process groups according to different execution content. All processes in a session must be descendants of the process of the session head, this ensures that these processes are directly or indirectly enabled by the head of the session. Only in this way can these processes be truly within the eyes and ears of the head of the session process. At the same time, the orphan process group is no longer under the control of the session head process.
Job:
There is only one terminal, but there are many things to be done at the same time or at least at the same time. What should I do if I cannot do one thing first? After all, after starting a process, the process will exclusively occupy the terminal. After all, shell will set it as a foreground process group process. This is the job function. You only need to add an & symbol to the end of a command. For example, if you want to execute X, enter:
X &
The shell result is:
[1] 1234
Here, 1234 is the PID of the process, and 1 is the job ID, so that this X does not occupy the terminal, shell can start other processes or jobs, for example, start job 2 again:
[2] 4321
In this case, you need to use the terminal to enter some information for Job 1, so you can use: FG % 1 to put Job 1 on the frontend (Job 1 currently has only one process ), how can I re-deploy a job at the front-end to the back-end? You only need to use the sigstop signal to stop the process of using the terminal at the front end, and then the process will open up the occupation of the terminal.
Process Group: a job is a process group. A single process can occupy only one process group or join other Process Groups in the same session. The conditions must be met, all processes in the same process group are the descendants of a session. The so-called process group is used to organize jobs or organize the same type of tasks.
Control terminal:
The creator of a session has the right to apply for a control terminal, which can accept standard input and send control shortcuts understood by shell, you can create a job and use the job control function provided by the session header process. The control terminal can only be created by the session header process, and the control terminal is exclusive. As long as one process treats a terminal as a control terminal, other processes cannot do this no matter who it is, the last few lines of code in tty_open are as follows:
If (! Noctty &&
Current-> signal-> leader &&
! Current-> signal-> tty &&
Tty-> session = 0 ){
Task_lock (current );
Current-> signal-> tty = tty;
Task_unlock (current );
Current-> signal-> tty_old_pgrp = 0;
Tty-> session = Current-> signal-> session; // sets the session
Tty-> pgrp = process_group (current );
}
It can be seen that other processes do not have permission to apply for control terminals.
Who does this control terminal usually use? The most suspicious session head has applied for a terminal, because even if he is suspicious, the Child processes that follow him are questionable, the terminal requested by the headers is used for these children. The headers divide these children into several Process Groups and designate a group as the front-end process group, only the processes in this foreground process group can use the control terminal. Bash usually exists as the session head. Bash creates a process group for all the executed commands. It sets the process as a foreground process group when receiving a command for execution, it will create a job and set it as a background process group when it accepts the command line plus the command "&". Who is the front-end, bash. Background processes cannot use terminals. If you use a process with internal functions such as getchar, it will receive the sigttin signal. However, you can use the FG command to bring these processes to the foreground.
Control Process:
Obviously, the process is the head of a session. In addition, even the head of a session can only control other processes through the terminal. The so-called control is to send signals rather than operate on memory, this is also a way of inter-process communication. Therefore, the so-called control process is the process applied to the control terminal.
Orphan process group:
There are orphan processes, and there are also the concept of orphan Process Groups. Why does the introduction of this concept require OS implementers? First, POSIX uses a session to describe a user's logon and the user's operations after this logon. Then, it uses the job to describe the content of different operations, finally, the concept of a process is used to describe a specific job in different operations. Secondly, Unix originally organized all the processes into a tree, in this way, it is easy to track every process and facilitate management (think about it, the human political society is also a tree-like structure: the monarchy, the two Houses system, etc ). With the above two prerequisites, we can understand that everything is for ease of management and for the security of login users, that is to say, this Login User's job cannot be controlled by the next login user, even if their usernames are consistent, therefore, the so-called orphan process group is simply separated from the process group that creates its session control, the process group that leaves its session eyeliner, and how to control the process in UNIX, how to prove whether it is in your own eyeliner is a tree structure. As long as the process in the subtree with its own root is the process in its own eyeliner, this process is protected, the process on other branches has the right to operate. In principle, the process on other branches cannot be touched (I want to say that Windows Remote threads have been created, but I need to talk about its complicated token mechanism, otherwise, Windows fans are not convinced, so do not mention it). In UNIX, the establishment process uses fork. Naturally, such a "fork" forms a branch of its own, of course, in its own eyes, generally, for a login user, a session starts with a shell after a login. As long as the user does not log out All non-daemon processes are the child processes of the shell, so they form a session, all in the shell eye, a session ends at the death of the session head. Now let's take a look at the shell exit scenario on the terminal. According to the regulations, all the processes on the terminal are forwarded to other processes, most of which are init processes, then another user logs on to the terminal or another bad user who knows the previous User Key logs on to the terminal, of course, a new session is created for the Shell started by the user. Since the previously logged-on user has exited, the logged-on user's process group has become an orphan process group, therefore, the attackers cannot control them any more. The members in the orphan process group either continue to run securely or are killed by the sighup signal sent when shell exits.
POSIX regulations are about iron discipline, while implementation of Unix or Linux, whether it is the kernel or shell, is a way to observe discipline. Iron's discipline requires that job control should be based on session, that is to say, you cannot operate process groups in other sessions. Therefore, commands such as FG and BG cannot operate orphan processes. Therefore, if the background process group is stopped by the sigstop signal due to the read/write terminal, then it becomes a member of the orphan process group. What should I do? Other session job control commands cannot operate on it. Even if PS-XJ finds it and manually sends sigcont, it still cannot use the terminal. This is another discipline requirement of POSIX, only the processes in the frontend process group in the session associated with the terminal can use the terminal. Therefore, if a shell exits, the best way is to kill all the processes in the session, therefore, sighup is intended to do this, but you can ignore this signal or define your own response to this signal. The basic limitation of POSIX is that the session ID cannot be set because it is the basic unit of protection, but the ID of the Process Group can be set. After all, it only distinguishes jobs that cannot be set, at last, the PID of the process cannot be set because it is a key attribute of the process to form a tree-like process structure.
POSIX defines orphan process groups: no parent process in the group belongs to the same session but is in different process groups.
Daemon:
The daemon must do the following:
1. fork is a sub-process: as Bash sets this program as a front-end process group process between fork and exec when executing the program, this is not set after fork here, then the child process becomes a background process and does not exclusively occupy a process group. The child process belongs to the Process Group of the parent process.
2. Call setsid to start a new session and start a new process group. The process becomes the head of a new session.
3. Fork a sub-process again. This will prevent the sub-process from re-applying for control terminal at the first fork. After all, it is the head of the session.
4. Disable all file descriptors, especially terminal-related descriptors such as 0, 1, and 2, because no terminal is available.
5 ....