IIS AppPoolIdentity 和文件系統寫訪問權限

Question

這是 IIS 7.5 和 ASP.NET 的一個問題，我一直在研究但無濟於事。 任何幫助將不勝感激。

我的問題是：在 IIS 7.5 中使用 ASP.NET，在完全信任的情況下運行時，IIS 和/或操作系統如何允許 Web 應用程序寫入像C:\\dump這樣的文件夾？ 為什么我不必為應用程序池用戶（在本例中為ApplicationPoolIdentity ）顯式添加寫訪問權限？

我知道的就這么多：

• 在 IIS 7.5 中，應用程序池的默認標識是ApplicationPoolIdentity 。
• ApplicationPoolIdentity代表一個名為“IIS APPPOOL\\AppPoolName”的Windows用戶賬號，它是在Application Pool創建的時候創建的，其中AppPoolName是Application Pool的名字。
• “IIS APPPOOL\\AppPoolName”用戶默認是IIS_IUSRS組的成員。
• 如果您在完全信任下運行，您的 Web 應用程序可以寫入文件系統的許多區域（不包括C:\\Users 、 C:\\Windows等文件夾）。 例如，您的應用程序將有權寫入某些文件夾，例如C:\\dump 。
• 默認情況下， IIS_IUSRS組沒有對C:\\dump讀或寫訪問權限（至少不是通過 Windows 資源管理器中的“安全”選項卡可見的訪問權限）。
• 如果您拒絕對IIS_IUSRS寫訪問，則在嘗試寫入文件夾時您將收到 SecurityException（如預期的那樣）。

那么，考慮到所有這些，如何向“IIS APPPOOL\\AppPoolName”用戶授予寫訪問權限？ w3wp.exe 進程以此用戶身份運行，那么是什么允許該用戶寫入它似乎沒有顯式訪問權限的文件夾？

請注意，我知道這樣做可能是為了方便起見，因為如果您在完全信任下運行，授予用戶訪問它需要寫入的每個文件夾的權限會很痛苦。 如果您想限制此訪問權限，您始終可以在中等信任度下運行該應用程序。 我有興趣了解操作系統和/或 IIS 允許這些寫入發生的方式，即使似乎沒有授予明確的文件系統訪問權限。

Answer 1

ApplicationPoolIdentity被分配了Users組和IIS_IUSRS組的成員身份。 乍一看，這可能有點令人擔憂，但Users組的 NTFS 權限有些有限。

例如，如果您嘗試在C:\\Windows文件夾中創建一個文件夾，那么您會發現您不能。 ApplicationPoolIdentity仍然需要能夠從 Windows 系統文件夾中讀取文件（否則工作進程將如何能夠動態加載必要的 DLL）。

關於您對能夠寫入c:\\dump文件夾的觀察。 如果您查看高級安全設置中的權限，您將看到以下內容：

看到從c:\\繼承的特殊權限：

這就是您站點的ApplicationPoolIdentity可以讀取和寫入該文件夾的原因。 該權利是從c:\\驅動器繼承的。

在共享環境中，您可能有數百個站點，每個站點都有自己的應用程序池和應用程序池標識，您可以將站點文件夾存儲在一個文件夾或卷中，該文件夾或卷已刪除了Users組並設置了權限，以便只有管理員和SYSTEM 帳戶具有訪問權限（具有繼承權）。

然后，您將單獨分配每個IIS AppPool\\[name]在其站點根文件夾上所需的必要權限。

您還應該確保您創建的任何用於存儲潛在敏感文件或數據的文件夾都刪除了Users組。 您還應該確保您安裝的任何應用程序不會將敏感數據存儲在其c:\\program files\\[app name]文件夾中，而是使用用戶配置文件文件夾。

所以是的，乍一看， ApplicationPoolIdentity似乎擁有比它應有的更多的權限，但實際上它沒有比它的組成員資格要求更多的權限。

可以使用 SysInternals Process Explorer 工具檢查ApplicationPoolIdentity的組成員身份。 找到使用您感興趣的應用程序池標識運行的工作進程（您必須將User Name名列添加到要顯示的列列表中：

例如，我這里有一個名為900300的池，它的應用程序池標識為IIS APPPOOL\\900300 。 右鍵單擊進程的屬性並選擇我們看到的安全選項卡：

正如我們所見， IIS APPPOOL\\900300是Users組的成員。

Answer 2

1. 右鍵單擊文件夾。

2. 單擊屬性

3. 單擊安全選項卡。 你會看到這樣的事情：

4. 單擊上面屏幕中的“編輯...”按鈕。 你會看到這樣的事情：

5. 單擊上面屏幕中的“添加...”按鈕。 你會看到這樣的事情：

6. 單擊上方屏幕中的“位置...”按鈕。 你會看到這樣的事情。 現在，轉到此樹結構的頂部並選擇您的計算機名稱，然后單擊“確定”。

7. 現在鍵入“iis apppool\\your_apppool_name”並單擊“檢查名稱”按鈕。 如果應用程序池存在，您將在帶有下划線的文本框中看到您的應用程序池名稱。 單擊確定按鈕。

8. 選中/取消選中您需要授予帳戶的任何訪問權限

9. 單擊應用按鈕，然后單擊確定。

Answer 3

默認情況下，IIs 中的每個應用程序池都會在 c:\\users 下創建自己的具有完全讀/寫權限的安全用戶文件夾。 打開您的用戶文件夾並查看那里有哪些應用程序池文件夾，右鍵單擊並檢查他們對分配的應用程序池虛擬帳戶的權限。 您應該會看到您的應用程序池帳戶已添加，並為其根文件夾和子文件夾分配了讀/寫訪問權限。

因此，這種類型的文件存儲訪問是自動完成的，您應該能夠在應用程序池用戶帳戶文件夾中寫入您喜歡的任何內容，而無需更改任何內容。 這就是為每個應用程序池創建虛擬用戶帳戶的原因。

Answer 4

我嘗試使用此方法來修復對 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組對該文件夾的讀取權限才能使其正常工作。