On the application pool security is concerned, we must ensure that w3wp.exe worker process can read the IIS configuration data, because this is the basis w3wp.exe worker process work properly. IIS settings w3wp.exe worker process must be able to read it serves the site. This means that the w3wp.exe worker process must have Read access to most content applicationHost.config file configuration. The question is: If each application pool can read the entire configuration file, then all of the information on the configuration file are exposed to each of the application pool. Therefore, we must ensure that: On the whole content applicationHost.config file, it does not allow each application pool has Read permissions or Write permissions to the overall content. Otherwise, some users can gain access to sensitive information.
To solve this problem, IIS development team proposed a method that allows read w3wp.exe worker process with all the relevant settings, but at the same time does not need to access information from other applications can not access the global data set sensitive, so can be completely configured isolation between different applications tools.
When the application pool is first started, Windows Process Activation Service (WAS) to get only the information related to the application pool, and C: create a temporary folder \ inetpub \ temp \ appPools \ directory, as this application pool settings ACL, and then the information is stored in the temporary folder. The following figure shows the saved WCF.Inventory.config file folder.
Most of the data is the same data applicationHost.config file .config file, but does not hold any other application pool of Web site information. We do not need to hold Web site information in other application pools .config file because w3wp.exe worker process is managed by the WAS, and w3wp.exe worker process does not require the use of their information.
If the data associated with the file change has occurred, then the temporary file will be updated. Otherwise, the file has been stored in the directory until IIS stops. If we delete this file, then IIS will be unable to perform the normal function of the application pool, all related to the application pool operations could cause failure, and only after IIS restarts, after regenerate the deleted files, this the problem can be resolved. If we just recycle the application pool, then the deleted files can not be regenerated, we can not solve this problem. Therefore, you must use these files unless incorrect positioning and, indeed, able to understand the functions of these documents and in various ways, it would be best not to carry out operations on the files.
Create temporary files in IIS 7.0 The whole process is a newly developed, thus ensuring the malicious code in one application pool can not read sensitive configuration data from the application pool.