IIS AppPoolIdentity и разрешения доступа на запись в файловой системе

Question

Вот проблема с IIS 7.5 и ASP.NET, которую я исследовал и до сих пор не нашел. Любая помощь будет принята с благодарностью.

Мой вопрос: используя ASP.NET в IIS 7.5, как IIS и / или операционная система позволяют веб-приложению записывать в папку, например C:\dump когда работает под полным доверием? Почему мне не нужно явно добавлять права на запись для пользователя пула приложений (в этом случае ApplicationPoolIdentity)?

Это много я знаю

• В IIS 7.5 идентификатор по умолчанию для пула приложений: ApplicationPoolIdentity,
• ApplicationPoolIdentity представляет учетную запись пользователя Windows с именем "IIS APPPOOL\AppPoolName", которая создается при создании пула приложений, где AppPoolName - это имя пула приложений.
• Пользователь "IIS APPPOOL \ AppPoolName" по умолчанию является членом IIS_IUSRS группа.
• Если вы работаете в режиме Full Trust, ваше веб-приложение может выполнять запись во многие области файловой системы (за исключением папок, таких как C:\Users, C:\Windows, так далее). Например, ваше приложение будет иметь доступ для записи в некоторые папки, например, C:\dump,
• По умолчанию IIS_IUSRS группе не предоставляется доступ для чтения или записи к C:\dump (по крайней мере, не доступ, который виден через вкладку "Безопасность" в проводнике Windows).
• Если вы отказываете в праве на запись в IIS_IUSRS, вы получите SecurityException при попытке записи в папку (как и ожидалось).

Итак, учитывая все это, как предоставляется доступ на запись пользователю "IIS APPPOOL \ AppPoolName"? Процесс w3wp.exe запускается от имени этого пользователя, так что же позволяет этому пользователю писать в папку, к которой у него нет явного доступа?

Обратите внимание, что я понимаю, что, вероятно, это было сделано для удобства, так как было бы затруднительно предоставить пользователю доступ ко всем папкам, в которые он должен писать, если вы работаете в режиме полного доверия. Если вы хотите ограничить этот доступ, вы всегда можете запустить приложение под Medium Trust. Я заинтересован в том, чтобы узнать, как операционная система и / или 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 имеет больше прав, чем должно, но на самом деле у него нет больше прав, чем требует членство в группе.

ApplicationPoolIdentity Членство в группе можно проверить с помощью инструмента SysInternals Process Explorer. Найдите рабочий процесс, который выполняется с интересующим вас идентификатором пула приложений (вам нужно будет добавить User Name столбец к списку столбцов для отображения:

Например, у меня есть пул здесь с именем 900300 который имеет идентификатор пула приложений IIS APPPOOL\900300, Если щелкнуть правой кнопкой мыши свойства процесса и выбрать вкладку "Безопасность", мы увидим:

Как мы можем видеть IIS APPPOOL\900300 является членом Users группа.

Answer 2

1. Щелкните правой кнопкой мыши на папке.

2. Нажмите Свойства

3. Нажмите вкладку "Безопасность". Вы увидите что-то вроде этого:

4. Нажмите кнопку "Изменить..." на экране выше. Вы увидите что-то вроде этого:

5. Нажмите кнопку "Добавить..." на экране выше. Вы увидите что-то вроде этого:

6. Нажмите кнопку "Locations..." на экране выше. Вы увидите что-то подобное. Теперь перейдите в самый верх этой древовидной структуры и выберите имя своего компьютера, затем нажмите OK.

7. Теперь введите "iis apppool\your_apppool_name" и нажмите кнопку "Проверить имена". Если приложение существует, вы увидите его имя в текстовом поле с подчеркиванием. Нажмите кнопку ОК.

8. Установите / снимите флажок для доступа к учетной записи

9. Нажмите кнопку Применить, а затем ОК.

Answer 3

Я пробовал это, чтобы исправить проблемы с доступом к веб-сайту IIS, которые проявлялись примерно следующим образом в журналах событий → Windows → Приложение:

Имя журнала: Приложение
Источник:        ASP.NET 4.0.30319.0
Дата: 05.01.2012, 16:12:33
ID события:      1314
Категория задачи: веб-событие
Уровень: Информация
Ключевые слова: классический
Пользователь:          N/A
Компьютер:      SALTIIS01

Описание:
Код события: 4008 
Сообщение о событии: Ошибка авторизации файла для запроса. 
Время события: 05.01.2012, 16:12:33 
Время события (UTC): 06.01.2012, 12:12:33 
Идентификатор события: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Последовательность событий: 7 
Возникновение события: 3 
Код детали события: 0 

Информация о приложении: 
    Домен приложения: /LM/W3SVC/2/ROOT/Application/SNCDW-19-129702818025409890 
    Уровень доверия: Полный 
    Виртуальный путь приложения: /Application/SNCDW 
    Путь приложения: D:\Sites\WCF\Application\SNCDW\ 
    Имя машины:      SALTIIS01 

Обрабатывать информацию: 
    ID процесса: 1896 
    Имя процесса: w3wp.exe 
    Имя учетной записи: iisservice 

Запросить информацию: 
    URL-адрес запроса: http://webservicestest/Application/SNCDW/PC.svc 
    Путь запроса: /Application/SNCDW/PC.svc 
    Адрес хоста пользователя: 10.60.16.79 
    Пользователь: js3228 
    Подтверждено: True 
    Тип аутентификации: переговоры 
    Имя учетной записи потока: iisservice 

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

Answer 4

Каждый пул приложений в IIs создает собственную защищенную пользовательскую папку с ПОЛНЫМ разрешением на чтение / запись по умолчанию в папке c:\users. Откройте папку "Пользователи" и посмотрите, какие папки пула приложений есть, щелкните правой кнопкой мыши и проверьте их права для назначенной виртуальной учетной записи пула приложений. Вы должны увидеть, что ваша учетная запись пула приложений уже добавлена ​​с правами чтения / записи, назначенными для ее корня и вложенных папок.

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