IIS AppPoolIdentity 和文件系统写访问权限 [英] IIS AppPoolIdentity and file system write access permissions

问题描述

这是 IIS 7.5 和 ASP.NET 的一个问题，我一直在研究但无济于事.任何帮助将不胜感激.

Here's an issue with IIS 7.5 and ASP.NET that I've been researching and getting nowhere with. Any help would be greatly appreciated.

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

My question is: using ASP.NET in IIS 7.5, how does IIS and/or the operating system allow the web application to write to a folder like C:dump when running under full trust? How is it that I don't have to explicitly add write access for the application pool user (in this case ApplicationPoolIdentity)?

我知道的就这么多:

• 在 IIS 7.5 中，应用程序池的默认标识是 ApplicationPoolIdentity.
• ApplicationPoolIdentity 代表一个名为IIS APPPOOLAppPoolName"的 Windows 用户帐户，它是在创建应用程序池时创建的，其中 AppPoolName 是应用程序池的名称.
• IIS APPPOOLAppPoolName"用户默认是 IIS_IUSRS 组的成员.
• 如果您在完全信任下运行，您的 Web 应用程序可以写入文件系统的许多区域(不包括C:Users、C:Windows 等文件夹)， 等等).例如，您的应用程序将有权写入某些文件夹，例如 C:dump.
• 默认情况下，IIS_IUSRS 组没有被授予对 C:dump 的读或写访问权限(至少不是通过安全"选项卡可见的访问权限)Windows 资源管理器).
• 如果您拒绝对 IIS_IUSRS 的写访问权限，则在尝试写入文件夹时会收到 SecurityException(正如预期的那样).

• In IIS 7.5, the default Identity for an Application Pool is ApplicationPoolIdentity.
• ApplicationPoolIdentity represents a Windows user account called "IIS APPPOOLAppPoolName", which is created when the Application Pool is created, where AppPoolName is the name of the Application Pool.
• The "IIS APPPOOLAppPoolName" 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 APPPOOLAppPoolName"用户授予写访问权限?w3wp.exe 进程以该用户身份运行，那么是什么允许该用户写入它似乎没有显式访问权限的文件夹?

So, taking all of that into account, how is write access granted to the "IIS APPPOOLAppPoolName" user? The w3wp.exe process runs as this user, so what allows this user to write to a folder it doesn't seem to have explicit access to?

请注意，我知道这样做可能是为了方便起见，因为如果您在完全信任下运行，授予用户访问它需要写入的每个文件夹的权限会很痛苦.如果您想限制此访问权限，您始终可以在中等信任度下运行该应用程序.我有兴趣了解操作系统和/或 IIS 允许这些写入发生的方式，即使似乎没有授予明确的文件系统访问权限.

Please note that I understand this was probably done for the sake of convenience, since it would be a pain to grant a user access to every folder it needs to write to if you are running under Full Trust. If you want to limit this access, you can always run the application under Medium Trust. I am interested in finding out about the way the operating system and/or IIS allows these writes to take place, even though there appears to be no explicit file system access granted.

推荐答案

ApplicationPoolIdentity 被分配了 Users 组以及 IIS_IUSRS 的成员资格代码>组.乍一看，这可能有点令人担忧，但是 Users 组的 NTFS 权限有些有限.

The ApplicationPoolIdentity is assigned membership of the Users group as well as the IIS_IUSRS group. On first glance this may look somewhat worrying, however the Users group has somewhat limited NTFS rights.

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

For example, if you try and create a folder in the C:Windows folder then you'll find that you can't. The ApplicationPoolIdentity still needs to be able to read files from the windows system folders (otherwise how else would the worker process be able to dynamically load essential DLL's).

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

With regard to your observations about being able to write to your c:dump folder. If you take a look at the permissions in the Advanced Security Settings, you'll see the following:

看到从 c: 继承的特殊权限:

See that Special permission being inherited from c::

这就是您网站的ApplicationPoolIdentity 可以读取和写入到该文件夹​​的原因.该权限是从 c: 驱动器继承的.

That's the reason your site's ApplicationPoolIdentity can read and write to that folder. That right is being inherited from the c: drive.

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

In a shared environment where you possibly have several hundred sites, each with their own application pool and Application Pool Identity, you would store the site folders in a folder or volume that has had the Users group removed and the permissions set such that only Administrators and the SYSTEM account have access (with inheritance).

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

You would then individually assign the requisite permissions each IIS AppPool[name] requires on it's site root folder.

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

You should also ensure that any folders you create where you store potentially sensitive files or data have the Users group removed. You should also make sure that any applications that you install don't store sensitive data in their c:program files[app name] folders and that they use the user profile folders instead.

是的，乍一看，ApplicationPoolIdentity 似乎拥有比它应有的更多的权限，但实际上它没有比其组成员身份要求的更多的权限.

So yes, on first glance it looks like the ApplicationPoolIdentity has more rights than it should, but it actually has no more rights than it's group membership dictates.

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

An ApplicationPoolIdentity's group membership can be examined using the SysInternals Process Explorer tool. Find the worker process that is running with the Application Pool Identity you're interested in (you will have to add the User Name column to the list of columns to display:

例如，我这里有一个名为 900300 的池，它的应用程序池标识为 IIS APPPOOL900300.右键单击进程的属性并选择我们看到的安全选项卡:

For example, I have a pool here named 900300 which has an Application Pool Identity of IIS APPPOOL900300. Right clicking on properties for the process and selecting the Security tab we see:

正如我们所见，IIS APPPOOL900300 是 Users 组的成员.

As we can see IIS APPPOOL900300 is a member of the Users group.

这篇关于IIS AppPoolIdentity 和文件系统写访问权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！