Windows notes-sharing kernel objects across process boundaries [inheritance of object handles]

Address: http://www.cnblogs.com/fangyukuan/archive/2010/08/31/1813698.html

These are all conceptual things that may seem annoying. But looking back at the multi-thread and memory management behind them, we may feel different.

 

In many cases, threads running in different processes need to share kernel objects. The reasons for sharing are as follows:

• The file ing object allows you to share data blocks between two processes running on the same machine.

• Email addresses and specified pipelines enable applications to send data blocks between processes running on different machines connected to the Internet.

• Mutex objects, beacons, and events allow threads in different processes to synchronize their continuous operation, this is the same as notifying another application of the situation when an application completes a task.

 

There are three methods to share kernel objects across process boundaries:

1. Inheritance of object handles
2. Named object
3. Copy object handle

Inheritance of object handles

The inheritance of object handles can be used only when a process has a parent-child relationship.

First, when the parent process creates a kernel object, it must specify to the system that it wants the object's handle to be an inherited handle. (Although the kernel object handle is inherited, the kernel object itself does not .)

To create an inherited handle, the parent process must specify a security_attributes structure and initialize it. Then, the address of the structure is passed to the specific create *** function. The following code creates a mutex object and returns an inherited handle to it:

   SECURITY_ATTRIBUTES sa;   sa.nLength = sizeof(sa);   sa.lpSecuntyDescriptor = NULL;   sa.bInheritHandle = TRUE;   HANDLE hMutex = CreateMutex(&sa, FALSE,NULL);

The flag stored in the Process Handle table project. Each handle table project has a flag to indicate whether the handle is inherited. If the binherithandle member is set to true, the flag is set to 1.

Process Handle table containing two valid projects

Index	Pointer to the memory block of the kernel object	Access blocking (DWORD of the Flag)	Sign (DWORD of the Flag)
1	0 x F 0 0 0 0 0 0 0	0 x? ? ? ? ? ? ? ?	0x0 0 0 0 0 0 0 0
2	0x0 0 0 0 0 0 0 0	(None)	(None)
3	0 x F 0 0 0 0 0 1 0	0 x? ? ? ? ? ? ? ?	0x0 0 0 0 0 0 1

Let the parent process generate a child process

When the object handle is used for inheritance, the next step is to let the parent process generate a child process. This should be done using the CreateProcess function:

BOOLCreateProcess(   PCTSTR pszApplicationName,   PTSTR pszCommandLine,   PSECURITY_ATTRIBUTES psaProcess,   PSECURITY_ATTRIBUTES psaThread,   BOOL bInheritHandles,   DWORD fdwCreale,   PVOIO pvEnvironment,   PCTSTR pszCurDir,   PSTARTUPINFO psiStartInfo,   PPROCESS_INFORMATION ppiProcInfo);

 

If the binherithandle parameter is set to true, the child process can inherit the inherited handle value of the parent process. When true is passed, the operating system creates the new sub-process, but does not allow the sub-process to execute its code immediately. Of course, the system creates a new and empty handle table for the child process, just as it creates a handle table for any new process. However, because true is passed to the binherithandles parameter of CreateProcess, the system needs to perform another operation, that is, it needs to traverse the handle table of the parent process, for each project that contains a valid inherited handle, the system accurately copies the project to the sub-process handle table. The position in the project copy to the sub-process handle table will be exactly the same as that in the parent process handle table. This situation is very important because it means that in the parent process and child process, the handle value used to identify the kernel object is the same.

In addition to the copy handle table project, the system also needs to increase the use count of the kernel object, because now both processes use this object. To cancel a kernel object, the parent process and child process must call the closehandle function on the object or terminate the process. The child process does not have to terminate the operation first, but the parent process does not have to terminate the operation first. In fact, after the CreateProcess function returns, the parent process can immediately close the handle of the object without affecting the sub-process's ability to operate on the object.

To determine the handle value of the desired kernel object, the most common method for a child process is to pass the handle value as a command line parameter to the child process, the initialization code of the sub-process analyzes the command line (usually by calling the s c a n f function) and retrieves the handle value. Once a sub-process has this handle value, it has unlimited access to this object. The only reason for the ownership of a handle is that the handle value of the shared kernel object in the parent and child processes is the same, this is why the parent process can pass the handle value as a command line parameter.

Of course, other forms of inter-process communication can be used to transmit the inherited kernel object handle value from the parent process to the child process. One way is to wait for the parent process to complete initialization. Then, the parent process can send a message or display it in a window created by a thread in the child process.

Another method is to allow the parent process to add an environment variable to its environment block. The name of the variable is the information that the sub-process knows to search for, and the value of the variable is the value to be inherited by the kernel object. In this way, when a parent process generates a child process, the child process inherits the environment variables of the parent process and can easily call the getenvironmentvariable function to obtain the handle value of the inherited object. If a sub-process generates another sub-process, this method is excellent because environment variables can be inherited again.

 

Flag for changing the handle

Sometimes, the parent process creates a kernel object to retrieve the inherited handle and then generates two child processes. The parent process only wants a child process to inherit the handle of the kernel object.

In other words, you may want to control which sub-process to inherit the handle of the kernel object.

To change the inheritance flag of the kernel object handle, you can call the sethandleinformation function:

BOOLSetHandleInformation(   HANDLE hObject,   DWORD dwMask,   DWORD dwFlags);

The first hobject parameter is used to identify a valid handle.

The second parameter dwmask tells the function which or which signs it wants to change. Currently, two labels are associated with each handle:

# Define handle flag_inherit 0x00000001

# Define HANDLE flag protect from close0x00000002

If you want to change the two flags of the object at the same time, you can use o r to connect these flags one by one.

The third parameter is dwflags, which indicates the value of the flag.

 

For example, to enable the inheritance flag of a kernel object handle, create the following code:

SetHandleInformation(hobj, HANDLE_FLAG_INHERIT,  HANDLE_FLAG_INHERIT);

To disable the flag, create the following code:

SetHandleInformation(hobj,HANDLE_FLAG_INHERIT, 0);

 

Handle_flag_protect_from_close indicates that the handle should not be closed:

Sethandleinformation (hobj, handle_flag_protect_from_close,

Handle_flag_protect_from_close );

Closehandle (hobj); // exception is raised

 

If a thread tries to close a protected handle, closehandle will generate an exception condition. It is seldom necessary to protect the handle so that others cannot close it. However, if a process generates a child process and the child process generates a child process, this flag may be useful. The parent process may want the sun process to inherit the object handle granted to the child process. However, the sub-process may close the handle before the sun process is generated. In this case, the parent process cannot communicate with the sun process because the sun process does not inherit the kernel object. By marking the handle as "protected cannot be closed", Sun Jin can inherit this object.

However, there is a problem with this method. The sub-process can call the following code to close the handle_flag_protect_from_close flag and then close the handle.

Sethandleinformation (hobj, handlemflag_prolecl_from_close, 0 );

Closehandle (hobj );

 

Gethandleinformation function:

BOOLGetHandleInformation(   HANDLE hObj,   PDWORD pdwFlags);

This function returns the setting value of the current flag of a specific handle in DWORD pointed to by pdwflags.

To check whether the handle is extensible, use the following code:

   DWORD dwFlags;   GetHandleInformation(hObj, &dwFlags);   BOOL fHandleIsInheritable = (0 != (dwFlags& HANDLE_FLAG_INHERIT));