Разрешение идентификатора пула приложений IIS 7.5 не назначено для папки, но приложение все еще может записывать в свою папку?

Мы разместили существующее приложение на новом сервере R2 с IIS 7.5.

Теперь все работает, и приложение может писать в него папки... но нам интересно, как... новый IIS поставляется с рассказом об идентификаторе пула приложений IIS, который создает нового виртуального пользователя для каждого приложения, и поэтому он сделал для этот.

В документации указано, что этот пользователь должен быть назначен папкам, чтобы все работало... но в нашем случае это не так?! И все-таки это работает, приложение через этого пользователя имеет доступ?

Где-то на форумах кто-то упоминал, что это потому, что приложения, работающие под полным доверием, могут писать что угодно где угодно... но это не имеет смысла? CAS в том, что я знаю, не справляется с этим?

Итак, в соответствии с IIS 7.5, как приложение с собственным пулом имеет права на запись, которые не находятся под настройками безопасности в папке?

Владан

Ответ 1

ИЗМЕНИТЬ

В то время как я чувствую, что я изложил ниже, является хорошим обсуждением того, как уровни доверия играют в доступ к файловой системе в ASP.NET, я чувствую, что правильный ответ на исходный вопрос отправлен здесь (да, я должен был задать этот вопрос с добавлением немного дополнительной информации). В принципе, пользователь AppPoolIdentity также является членом группы Users, и именно так пользователь может писать в разные области файловой системы.

ORGINAL ANSWER:

Когда вы создаете новый пул приложений в IIS 7.5, пользователь AppPoolIdentity добавляется в группу IIS_IUSRS. Эта группа имеет "доступ ко всем необходимым файловым и системным ресурсам, чтобы учетная запись при добавлении в эту группу могла беспрепятственно действовать как идентификатор пула приложений" (1). Группа IIS_IUSRS имеет права на запись в подавляющую часть файловой системы (вне защищенных папок, таких как C: \, C:\Users, C:\Windows и т.д.). К сожалению, я не смог найти какой-либо способ явно увидеть, что группа IIS_IUSRS имеет доступ к данной папке с помощью проводника Windows (edit). В приведенной выше статье описывается, как "видеть" этот доступ), Однако этот доступ можно увидеть неявно, предоставив DENY доступ к группе IIS_IUSRS в папке, прежде чем пытаться записать в эту папку (что вызовет System.UnauthorizedAccessException).

Уровни доверия .NET также учитываются в разрешениях. В IIS 7.5 пользователь IIS AppPoolIdentity имеет доступ к записи в папку, в которой приложение запущено по умолчанию, если веб-приложение работает под полным, высоким или средним уровнем доверия. При работе под полным или высоким доверием пользователь IIS AppPoolIdentity по умолчанию может писать в любую папку, отличную от таких, как C: \, C:\Windows или C:\Users (если пользователю не предоставлен конкретный доступ к этим папкам). На уровне среднего уровня доверия пользователь IIS AppPoolIdentity по-прежнему может писать в папку веб-приложения по умолчанию, но попытка записи в любую другую папку приводит к следующему исключению:

System.Security.SecurityException: Запрос разрешения типа "System.Security.Permissions.FileIOPermission, mscorlib, Version = 4.0.0.0, Culture = нейтрально, PublicKeyToken = b77a5c561934e089' не удалось.

Такое же исключение возникает при попытке записи в ЛЮБОЙ файл с низким или минимальным уровнем доверия.

Это не та же ошибка, которую вы получаете при попытке получить доступ к файлу, к которому пользователь AppPoolIdentity не имеет доступа при работе под полным или высоким доверием. Исключение, созданное в этом случае, - это System.UnauthorizedAccessException, с сообщением, похожим на:

System.UnauthorizedAccessException: Доступ к пути "C:\test.txt" отказано.

На средних, низких или минимальных уровнях доверия CAS берет на себя и отказывает в доступе к методам создания файлов, независимо от прав на доступ к папкам.

Краткая история заключается в том, что если вы хотите, чтобы ваше веб-приложение не могло писать в любые папки, отличные от папки веб-приложения, вам нужно настроить запуск приложения под средним доверием или ниже. Если вы это сделаете, вам нужно протестировать, чтобы убедиться, что нет функций, которые необходимо выполнить приложениям, для которых требуется более высокий уровень доверия.

Литература:

1 - http://learn.iis.net/page.aspx/140/understanding-built-in-user-and-group-accounts-in-iis-7/

2 - http://technet.microsoft.com/en-us/library/dd163542.aspx