Linux process overview

First, Introduction

When a process in a Linux system runs, it always accesses the resources of the system, accesses the files, or sends a signal to other processes. Does the system allow it to do these things? What is the system's ability to determine the permissions of the process? These issues are related to process credentials.

Process credentials includes a series of IDs, as follows:

1. Real user ID and real group ID

2. Effective user ID and effective group ID

3, saved Set-user-id and saved Set-group-id

4. File-system User ID and File-system group ID

5. Supplementary group IDs

Second, what is real user ID and real group ID

The real user ID and real group ID identify which user (which group) the process belongs to. Both the real user ID and the real group ID of the Swapper and init processes are set to root (Id=0), and when the user logs in, the real user ID and real group ID of the corresponding shell process are set to the logged-on user. This is set by the login process called setuid function. In the fork process, the credentials of the child process is inherited from its parent process.

Iii. What is effective user ID and effective group ID

As it is named, it is true to check whether a process has permission to perform certain actions (such as accessing the IPC object, requesting kernel services through a system call, etc.), which is the effective user ID and the effective group ID. Generally, the effective user ID (effective group ID) is the same as the real user ID (real group ID), but if the executable file is set to Set-user-id (Set-group-id), Then when the process is created, its effective user ID and effective group ID are equal to the user ID of the executable file, respectively.

Iv. what is saved Set-user-id and saved Set-group-id

These IDs are defined in the task_struct in Linux kernel as follows:

uid_t Uid,euid,suid,fsuid;

gid_t Gid,egid,sgid,fsgid;

Here Suid (Sgid) represents saved Set-user-id (saved Set-group-id), where the variable name is very unfriendly, the surface looks like Save the real ID, but actually save the effective ID. Why save effective ID? This is in fact related to a guideline: a process should run with the smallest possible privileges. Most embedded software engineers will ignore this because the embedded system is basically not multi-user, and developers are logged into the system with root, all in charge. In addition, saved Set-user-id (saved Set-group-id) is associated with Set-user-id (Set-group-id). For example, Zhang San starts an executable program that owner is root, and the program sets the Set-user-id bit, so when the program executes, the real user ID is Zhang San, and the effective User ID is root,saved Set-user-id is also root because it is a copy from the effective user ID. The process does not always require root permissions, so the criteria for running the process should be as small as possible, and the effective user ID of Zhang San (for unprivileged users) can be modified by system call when no root privileges are required, effective The user ID can only be toggled between the real user ID and saved Set-user-id. When Root is required, the effective user ID can be modified back to root through a system call. Because of this, the process requires a saved Set-user-id to hold the original effective user ID.

The same applies to saved Set-group-id, which is not covered here.

V. What is File-system User ID and File-system group ID

This ID is unique to Linux, and traditional UNIX does not have this ID. For traditional UNIX, access to files, send signal, open IPC object, and so on are based on the effective ID. For Linux, the remaining permissions are still determined by the effective ID, but access to the file uses the File-system user ID and the File-system group ID (which, of course, needs to match supplementary group IDs).

In Linux kernel, the File-system user ID (file-system group ID) is followed by the effective user ID (effective group ID). For example, if the owner is the root executable file if the Set-user-id bit is set, then when the program executes, the effective user ID is Root,file-system user ID is also followed effective user The ID is set to root. If you modify the effective user Id,file-system user ID through a system call, it will also be modified. This ensures that Linux has the same rights to judge as traditional UNIX. The difference is that Linux provides two special system calls Setfsuid () and Setfsgid () to set the File-system user ID and File-system group ID of the process.

Why does Linux introduce File-system user ID and file-system group ID? This is related to NFS (Network File System). Consider the following scenario: A host running the NFS server process opens its file system, and the B host running the NFS client process can access the file of a host through the Mount NFS file system as if it were accessing a local file. In such a scenario, the NFS client process accesses a file on a host that should certainly apply the NFS client's effective ID, but because it is a network file system, the NFS server process actually accesses the file. If you modify the effective ID of NFS server, the process of user space can be attacked by sending signal to NFS server. There are two ways to solve this problem:

1. Do not modify effective ID, introduce File-system User ID (file-system group ID)

2, modify the effective ID, change the mechanism of signal transmission. That is, when a process sends a signal to the B process, whether the operation is allowed to be no longer related to the effective ID of the B process.

Schema one was adopted in earlier versions of Linux kernel, but the kernel version after 2.0 adopted scenario two. Therefore, the File-system user ID and the File-system group ID should be deprecated, but for software compatibility, the Linux kernel still retains the two File-system IDs.

Vi. What is supplementary group IDs

When a user logs in, the Loggin program (whose user ID is root) verifies the password based on the information in/etc/passwd (and/etc/shadow) and sets the user ID and first group ID of the shell process for the logged-on users. Because a user ID may belong to more than one group, through the/etc/group file, the Loggin program can know which group the user belongs to and set supplementary group IDs for the logged-on user's shell process.

When a user creates a new process through the shell, the supplementary group IDs of the child processes are inherited from their parent processes. Supplementary group IDs will work with the File-system ID and effective ID to determine whether the process has access to certain resource permissions.

I. Overview

This article describes how to identify one or a group of entities that are related to processes (threads) in Linux kernel, including:

1. Process ID (thread group ID)

2. Thread ID

3. Process Group ID

4. Session ID

It should be emphasized that this article focuses on identification, and many of the expanded content will have a series of document descriptions.

Ii. What is the process ID (thread group ID)

In general, we will define whether a process is an executing program or a running instance of a program. A program is a static concept that is a binary executable that is stored on disk, including program code and data (body segments, data segments, and so on). When a program runs as a process, simple program code does not clearly describe the process, it also requires several data structures to describe the execution state of the program (Hardware context and software context) and the resources (such as address space, open file descriptors, and so on). From the kernel point of view, a process is an entity that is related to system resources (CPU time, memory, and so on).

In the POSIX standard, the system defines the GETPID function to get the process ID of a procedure. In Linux kernel, the definitions are as follows:

Asmlinkage long sys_getpid (void)

{

Return current->tgid;

}

Literally, the tgid in Task_struct is the thread group ID, which is the threading set ID, in Linux kernel, the process has one or more thread components (POSIX specifies that multiple threads share a process ID). For Linux kernel, each thread is assigned a task_struct (which has a PID identifier), which is not the same as most kernel processing, and the other kernel assigns a task_struct to a process where the task_ The data for each thread belonging to the process is embedded in the struct. Because of this, Linux kernel creates a thread group concept that maps to the process concept in POSIX.

The PID of the first thread (the main thread, group leader) in the multithreaded process equals Tgid, after which the threads in the thread group have their own PID, but the shared Tgid, which is the process ID in the traditional sense. Task_struct has a Group_leader member that points to the thread group leader for the task, and for group leader, the member points to its own TASK_STRUCT data structure.

Third, what is the thread ID

A thread is an entity in a process, which is the basic unit of dispatch and dispatch by the system, and the thread itself does not own the system resources independently, it is all the resources (such as address space, file descriptor, and signal processing) that the process shares with other threads of the same process. This first shows that all threads have the same address space (the process's address space), which means that the thread can access every virtual address in that address space, and also access resources such as open files, timers, semaphores, and so on, that the process owns. A process is the smallest unit of resource management, and a thread is the smallest unit that a program executes. In addition to the shared process resources, each thread in the process also belongs to its own resources, including: Stack, PC counter, and CPU registers.

Each thread should have its own ID, which is the thread ID, in Linux kernel, each thread is assigned a task_struct, and the PID member in the structure is the thread ID. In the POSIX standard, pthread_self is defined to get the thread Id,linux kernel takes the Gettid system call to get the caller's thread ID. In Linux kernel, the definitions are as follows:

Asmlinkage long Sys_gettid (void)

{

Return current->pid;

}

POSIX specifies that the thread ID is unique within the owning process, but in the implementation of the Linux kernel, the thread ID is unique across the system, and of course, given portability, application software should not assume this.

Iv. What is the process group ID

Each process belongs to a process group, and each process group has a leader process, which is the process ID that equals the process group ID. The process group has a life cycle, and its life cycle starts at the process group leader create the process group, ending with the last process in the process group leaving the process group (either the process exits, or joins another process group). The concept of process group is presented mainly because:

1, and job control-related, about job control, follow-up special document detailed description.

2. Signal can be sent to every process in the process group (job control also uses this feature.) For example, job control signal is sent to every process in the job (process Group))

3. When the process is synchronized, the parent process can wait for any one of the processes in the for process group

In the POSIX standard, the system defines the Getpgid function to get the process group ID of a procedure. In Linux kernel, the definitions are as follows:

Asmlinkage long Sys_getpgid (pid_t pid)

{

if (!pid) {

If the PID equals 0, then you need to get the process group ID of the current process

return Process_group (current);

}

else {

Otherwise, the process group ID corresponding to the process that gets the PID identity

int retval;

struct Task_struct *p;

Read_lock (&tasklist_lock);

p = find_task_by_pid (PID);

retval =-esrch;

if (p) {

Whether there is a right to get the process group ID of another process

retval = Security_task_getpgid (p);

if (!retval)

retval = Process_group (p);

}

Read_unlock (&tasklist_lock);

return retval;

}

}

Static inline pid_t process_group (struct task_struct *tsk)

{

Return tsk->signal->pgrp;

}

The PGRP member in signal in Task_struct identifies the process group ID. From the point of view of the PGRP, the process group should be related to signal processing, followed by a detailed description of the specific documentation.

V. Session ID

Similar to processes belonging to process groups, each process group belongs to a session, each session has a leader process, that is, the process of creating a session, session leader ID is equal to the session ID. The session concept is presented in connection with user login and terminal programming, followed by a detailed description of the specific documentation.

In the POSIX standard, the system defines the GETSID function to get the process group ID of the session leader session. If the specified PID is not session leader, an error is returned, but the rule is not fully adhered to in Linux kernel, the GETSID function can always return the session ID of the specified PID, regardless of whether the PID is pointing to a session Leader, specifically defined as follows:

Asmlinkage long Sys_getsid (pid_t pid)

{

if (!pid) {

If the PID equals 0, then you need to get the process group ID of the current process

return process_session (current);

}

else {

Otherwise, the process group ID corresponding to the process that gets the PID identity

int retval;

struct Task_struct *p;

Read_lock (&tasklist_lock);

p = find_task_by_pid (PID);

retval =-esrch;

if (p) {

retval = Security_task_getsid (p);

if (!retval)

retval = Process_session (p);

}

Read_unlock (&tasklist_lock);

return retval;

}

}

Static inline pid_t process_session (struct task_struct *tsk)

{

Return signal_session (tsk->signal);

}

Static inline pid_t signal_session (struct signal_struct *sig)

{

Return sig->__session;

}

The __session member in signal in Task_struct identifies the process group ID. From the point of view of __session, the session should also be related to signal processing, followed by detailed description.

Linux process overview