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

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

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

我知道这么多:

In IIS 7.5, the default Identity for an Application Pool is ApplicationPoolIdentity. ApplicationPoolIdentity represents a Windows user account called "IIS APPPOOL\AppPoolName", which is created when the Application Pool is created, where AppPoolName is the name of the Application Pool. The "IIS APPPOOL\AppPoolName" user is by default a member of the IIS_IUSRS group. If you are running under Full Trust, your web application can write to many areas of the file system (excluding folders like C:\Users, C:\Windows, etc). For example, your application will have access to write to some folders, like, C:\dump. By default, the IIS_IUSRS group is not given read or write access to C:\dump (at least not access that is visible through the "Security" tab in Windows Explorer). If you deny write access to IIS_IUSRS, you will get a SecurityException when trying to write to the folder (as expected).

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

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

当前回答

我试图修复访问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组对该文件夹的读访问权，以使其正常工作。

2020-01-14 10:07:31

其他回答

我试图修复访问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组对该文件夹的读访问权，以使其正常工作。

2020-01-14 10:07:31

右键单击文件夹。单击“属性” 单击“安全选项卡”。你会看到这样的东西:

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

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

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

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

勾选/取消勾选您需要授予该帐户的任何访问权限单击“应用”按钮，然后单击“确定”。

2017-10-02 17:05:25

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

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

2017-02-13 16:03:01

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

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

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

看到特殊权限继承自c:\:

这就是站点的ApplicationPoolIdentity可以读写该文件夹的原因。这个权限是从c:\ drive继承的。

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

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

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

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

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

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

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

2011-03-26 01:00:36

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

推荐文章

最新文章

标签