这里有一个关于IIS 7.5和ASP.NET的问题，我一直在研究，但却一无所获。任何帮助都将不胜感激
我的问题是：在IIS 7.5中使用ASP.NET，IIS和/或操作系统如何允许web应用程序在完全信任的情况下运行时写入C:\dump之类的文件夹？为什么我不必显式地为应用程序池用户添加写访问权限（在本例中为ApplicationPoolIdentity）
我知道的是：
- 在IIS 7.5中，应用程序池的默认标识为
ApplicationPoolIdentity ApplicationPoolIdentity表示名为“IIS APPPOOL\AppPoolName”的Windows用户帐户，该帐户在创建应用程序池时创建，其中AppPoolName是应用程序池的名称- 默认情况下，“IIS APPPOOL\AppPoolName”用户是
IIS\u IUSRS组的成员 - 如果您在完全信任的情况下运行，您的web应用程序可以写入文件系统的许多区域（不包括
C:\Users、C:\Windows等文件夹）。例如，您的应用程序将有权写入某些文件夹，例如，C:\dump - 默认情况下，
IIS\u IUSRS组没有对C:\dump的读写权限（至少没有通过Windows资源管理器中的“安全”选项卡可见的权限） - 如果拒绝对
IIS\u IUSRS的写入访问，则在尝试写入文件夹时（如预期的那样）将出现SecurityException
那么，考虑到所有这些因素，如何向“IIS APPPOOL\AppPoolName”用户授予写访问权限？w3wp.exe进程以该用户的身份运行，那么是什么允许该用户写入它似乎没有显式访问权限的文件夹呢
请注意，我理解这可能是为了方便起见，因为如果您在完全信任的情况下运行，那么授予用户对每个需要写入的文件夹的访问权限将是一件痛苦的事情。如果要限制此访问，可以始终在中等信任下运行应用程序。我感兴趣的是了解操作系统和/或IIS允许这些写入的方式，即使似乎没有授予明确的文件系统访问权限
ApplicationPoolIdentity被分配为Users组以及IIS\u IUSRS组的成员。乍一看，这可能有点令人担忧，但是用户组的NTFS权限有些有限
例如，如果您尝试在C:\Windows文件夹中创建一个文件夹，您会发现无法创建。ApplicationPoolIdentity仍然需要能够从windows系统文件夹中读取文件（否则工作进程将如何动态加载基本DLL）
关于您对能够写入c:\dump文件夹的观察。如果查看高级安全设置中的权限，您将看到以下内容：
查看从c:\继承的特殊权限：
这就是站点的ApplicationPoolIdentity可以读取和写入该文件夹的原因。该权限从c:\驱动器继承
在共享环境中，您可能有数百个站点，每个站点都有自己的应用程序池和应用程序池标识，您可以将站点文件夹存储在一个文件夹或卷中，该文件夹或卷中的用户组已被删除，权限设置为只有管理员和系统帐户可以访问（有继承权）
然后，您将分别为每个IIS AppPool\[name]在其站点根文件夹上分配所需的权限
您还应确保您创建的存储潜在敏感文件或数据的文件夹已删除用户组。您还应确保您安装的任何应用程序都不会在其c:\program files\[app name]on存储敏感数据文件夹，并使用用户配置文件文件夹
因此，是的，乍一看，它看起来像是ApplicationPoolIdentity拥有比它应该拥有的更多的权限，但实际上它拥有的权限并不比它的组成员资格所规定的权限多
可以使用SysInternals Process Explorer工具检查ApplicationPoolIdentity的组成员身份。查找使用您感兴趣的应用程序池标识运行的工作进程（您必须将用户名列添加到要显示的列列表中：
例如，我在这里有一个名为900300的池，其应用程序池标识为IIS APPPOOL\900300。右键单击进程的属性并选择安全选项卡，我们会看到：
如我们所见，IIS-APPPOOL\900300是Users组的成员