IIS AppPoolIdentity和文件系统写访问权限

下面是iis7.5和ASP的一个问题。NET，我一直在研究，但毫无进展。任何帮助都将不胜感激。

我的问题是:使用ASP。在IIS 7.5中，IIS和/或操作系统如何允许web应用程序在完全信任下运行时写入像C:\dump这样的文件夹?为什么我不需要显式地为应用程序池用户(在这种情况下ApplicationPoolIdentity)添加写访问?

我知道这么多:

  • 在iis7.5中，应用程序池的默认标识是ApplicationPoolIdentity。
  • ApplicationPoolIdentity表示一个名为“IIS APPPOOL\AppPoolName”的Windows用户帐户，该帐户是在创建应用程序池时创建的，其中AppPoolName是应用程序池的名称。
  • "IIS APPPOOL\AppPoolName"用户默认是IIS_IUSRS组的成员。
  • 如果你在完全信任下运行，你的web应用程序可以写入文件系统的许多区域(不包括像C:\Users， C:\Windows等文件夹)。例如，您的应用程序将有权写入一些文件夹，如C:\dump。
  • 默认情况下，IIS_IUSRS组不被赋予对C:\dump的读写权限(至少不能通过Windows资源管理器中的“Security”选项卡可见)。
  • 如果你拒绝对IIS_IUSRS的写访问，你会在试图写入文件夹时得到一个SecurityException(正如预期的那样)。

那么，考虑到所有这些因素，如何将写访问权限授予“IIS appppool \AppPoolName”用户?w3wp.exe进程作为该用户运行，那么是什么允许该用户写入它似乎没有显式访问权限的文件夹呢?

请注意，我理解这样做可能是为了方便，因为如果您在完全信任下运行，那么授予用户对需要写入的每个文件夹的访问权将是一件痛苦的事情。如果希望限制这种访问，可以始终在Medium Trust下运行应用程序。我对操作系统和/或IIS允许这些写入的方式感兴趣，即使似乎没有显式授予文件系统访问权。

317930 次浏览
小开
最佳答案

ApplicationPoolIdentity被指定为Users组和IIS_IUSRS组的成员。乍一看，这可能有点令人担忧，但是Users组有一些有限的NTFS权限。

例如，如果你尝试在C:\Windows文件夹中创建一个文件夹，那么你会发现你不能。ApplicationPoolIdentity仍然需要能够从windows系统文件夹中读取文件(否则工作进程如何能够动态加载必要的DLL)。

关于你对能够写入c:\dump文件夹的观察。如果你在高级安全设置中查看权限，你会看到以下内容:

enter image description here

特殊权限继承自c:\:

enter image description here

这就是你的站点的ApplicationPoolIdentity可以读取和写到该文件夹的原因。该权限是从c:\驱动器继承的。

在共享环境中，您可能有几百个站点，每个站点都有自己的应用程序池和应用程序池标识，您可以将站点文件夹存储在已删除Users组的文件夹或卷中，并且权限设置为只有管理员和SYSTEM帐户具有访问权限(具有继承)。

然后，您将在每个IIS AppPool\[name]的站点根文件夹上分别分配必要的权限。

您还应该确保您创建的任何用于存储潜在敏感文件或数据的文件夹都删除了Users组。你还应该确保你安装的任何应用程序不会在它们的c:\program files\[app name]文件夹中存储敏感数据，而是使用用户配置文件文件夹。

所以，是的，乍一看ApplicationPoolIdentity似乎拥有比它应该拥有的更多的权利，但实际上它所拥有的权利并不比它的组成员资格所规定的更多。

ApplicationPoolIdentity的组成员关系可以使用SysInternals 进程资源管理器工具检查。找到与你感兴趣的应用程序池标识一起运行的工作进程(你必须将User Name列添加到要显示的列列表中:

enter image description here

例如，我有一个名为900300的池，它的应用程序池标识为IIS APPPOOL\900300。右键单击进程的属性，然后选择Security选项卡:

enter image description here

正如我们可以看到的，IIS APPPOOL\900300是Users组的成员。

小开

IIs中的每个应用程序池在c:\users下默认创建自己的具有完全读写权限的安全用户文件夹。打开Users文件夹，查看有哪些应用程序池文件夹，右键单击，并检查分配的应用程序池虚拟帐户的权限。您应该看到已经添加了应用程序池帐户，并为其根文件夹和子文件夹分配了读/写访问权限。

这种类型的文件存储访问是自动完成的你应该可以在应用程序池用户帐户文件夹中写任何你想写的东西而不需要改变任何东西。这就是为每个应用程序池创建虚拟用户帐户的原因。

小开

  1. 右键单击文件夹。

  2. 单击“属性”

  3. 单击“安全选项卡”。你会看到这样的东西:

enter image description here

  1. 点击上方屏幕中的“编辑…”按钮。你会看到这样的东西:

enter image description here

  1. 点击上方屏幕中的“添加…”按钮。你会看到这样的东西:

enter image description here

  1. 点击屏幕上方的“位置…”按钮。你会看到类似这样的东西。现在，转到这个树结构的最顶端，选择您的计算机名，然后单击OK。

enter image description here

  1. 现在输入“iis apppool\your_apppool_name”，然后点击“检查名称”按钮。如果apppoool存在，您将在文本框中看到带有下划线的apppoool名称。单击OK按钮。

enter image description here

  1. 勾选/取消勾选您需要授予该帐户的任何访问权限

  2. 单击“应用”按钮，然后单击“确定”。

小开

我试着修复IIS网站的访问问题，这表现为事件日志→Windows→应用程序中的像下面这样:

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          1/5/2012 4:12:33 PM
Event ID:      1314
Task Category: Web Event
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SALTIIS01


Description:
Event code: 4008
Event message: File authorization failed for the request.
Event time: 1/5/2012 4:12:33 PM
Event time (UTC): 1/6/2012 12:12:33 AM
Event ID: 349fcb2ec3c24b16a862f6eb9b23dd6c
Event sequence: 7
Event occurrence: 3
Event detail code: 0


Application information:
Application domain: /LM/W3SVC/2/ROOT/Application/SNCDW-19-129702818025409890
Trust level: Full
Application Virtual Path: /Application/SNCDW
Application Path: D:\Sites\WCF\Application\SNCDW\
Machine name: SALTIIS01


Process information:
Process ID: 1896
Process name: w3wp.exe
Account name: iisservice


Request information:
Request URL: http://webservicestest/Application/SNCDW/PC.svc
Request path: /Application/SNCDW/PC.svc
User host address: 10.60.16.79
User: js3228
Is authenticated: True
Authentication Type: Negotiate
Thread account name: iisservice

最后，我不得不给Windows Everyone组读取该文件夹的访问权来让它正常工作。


提交答案