Handle and handle inheritance of kernel objects and kernel objects

Handle and handle inheritance of kernel objects and kernel objects
When creating a kernel object, you often need to specify its security attribute: security_attribute
This is a structure break and is defined as follows:
Typedef struct _ security_attributes {
DWORD nlength;
Lpvoid lpsecuritydescriptor;
Bool binherithandle;
} Security_attributes, * psecurity_attributes;
Binherithandle, the third member, specifies whether the created kernel object handle can be inherited by the quilt process. First, the inheritance relationship exists only between parent and child processes. Here, the parent and child process refers to a process that calls the CreateProcess function to create another process. The CreateProcess API is called by the parent process, the newly created process is a child process. How does a child process inherit the handle of the kernel object of its parent process? What handles does it inherit from its parent process?
Let's first look at the CreateProcess API function:
Bool CreateProcess (
Lptstr lpapplicationname, // name of executable module
Lptstr lpcommandline, // command line string
Lpsecurity_attributes lpprocessattributes, // SD
Lpsecurity_attributes lpthreadattributes, // SD
Bool binherithandles, // handle inheritance Option
DWORD dwcreationflags, // creation flags
Lpvoid lpenvironment, // New Environment Block
Maid directory, // current directory name
Lpstartupinfo, // startup information
Lpprocess_information lpprocessinformation
);
CreateProcess has many parameters. We will not consider other parameters first. We only consider bool binherithandles. If this parameter is true when CreateProcess is called, then, the created sub-process copies the kernel object handles that can be inherited from the parent process to the sub-process's memory before the master thread starts execution, the system scans the handle table of the parent process and copies the object handles that can be inherited from the handle table to the handle table of the child process, the so-called inherited handle means that when the parent process creates the handle, it specifies the binherithandle parameter as true in the security attribute description parameter mentioned earlier, if the binherithandle Member of the Security Attribute when the handle is created is false, the system does not copy the handle. Because the kernel object does not belong to any process, but belongs to the operating system, the process can only access the kernel object through the handle of the kernel object, so the system only copies the handle, because the parent process does not own the kernel object, it does not matter to copy the kernel object. The child process only inherits the handle that can be used to access the kernel object from the parent process. Therefore, although the handle of the kernel object is copied, the kernel object has only copies in the system, and both parent and child processes have the handles that can access the kernel object at the same time, but none of them own this kernel object. The system adds the reference count of the kernel object to 1 When copying the kernel object handle. if CreateProcess is called, the parent process creates an inherited Kernel Object OBJ, and the parent process accesses the kernel object's handle hobja, the reference count of this kernel object is 1, when CreateProcess creates a sub-process, the binherithandle parameter is true. After the sub-process is created, the system copies the parent Process Handle hobja to the sub-process handle, the sub-process has a new handle hobjb. The sub-process can use this handle hobjb to access the kernel object obj. the kernel object obj is unique throughout the system. The parent process accesses it through the kernel object handle hobja, and the child process accesses it through hobjb. In this case, the reference count of obj is 2. here, if you want the system to release the OBJ kernel object, you must call the closehandle API twice, call closehandle (hobja) at one time in the parent process, and call closehandle (hobjb) at one time in the child process ), each time closehandle is called, the reference count of obj is reduced by 1. When it is reduced to 0, the system determines that no process uses OBJ, And it is automatically released. Note that calling closehandle (hobja) twice in the parent process will not release obj. If it is under VC debugging, the second closehandle (hobja) will send and receive an exception. Because closehandle (hobja) is called for the first time, the system will reduce the reference count of OBJ by 1, and the reference count of obj is 1. The system will not release this kernel object, however, the system will clear the hobja entry in the parent process's handle table. During the second call, the system will throw an exception if the corresponding handle entry of hobja in the handle table is invalid, OBJ will not be released until the sub-process calls closehandle (hobjb), or the sub-process stops running itself, and the reference count of obj is reduced to 0. remember to call closehandle (hobja) to clear hobja from 0,
Closehandle (hobja );
Hobja = NULL;
The handle value of the kernel object is actually the index of the handle in the Process Handle table. The first item of the handle is not used. When a child process inherits the kernel object handle from the parent process, the system will add the inherited handle at the same location in the child process handle table, that is, the value of the inherited handle is the same. That is to say
Parent process. hobja = child process. hobjb
Yes