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

Я уверен, что у этой аномалии есть логическое объяснение, но мне интересно, что это такое.

Вот установка:

1. Создайте папку TEST на локальном диске (C:\TEST)
2. Настройте новый сайт IIS и пул приложений (назовите это ТЕСТ) - укажите на него C:\Test и установите его как ApplicationPoolIdentity.
3. Создайте простой index.html файл в C:\TEST
4. Удалите все разрешения из C: \ TEST, кроме обычных Administrators, SYSTEM, и TrustedInstaller. Не существует обычных пользовательских разрешений.

Сценарий 1:

• Попробуйте просмотреть новый сайт.
• Обратите внимание, что пользователь получает сообщение об ошибке.

Сценарий 2:

• Добавить Read разрешения на C:\TEST для IIS AppPool\TEST
• Обновите окна браузера и убедитесь, что Index.html отображается правильно.

Сценарий 3:

• + Изменить TEST удостоверение пула приложений для запуска от имени пользователя домена (domain\test). Перезапустите пул приложений.
• Обновите браузер и обратите внимание, что пользователь все еще может получить доступ к странице Index.html.
• Подтвердите в диспетчере задач, что сайт действительно работает как Domain\Test.

Сценарий 4:

• удалять IIS AppPool\TEST разрешения на C:\TEST.
• Обновите браузер и посмотрите, как пользователь получает сообщение об ошибке.

Сценарий 5:

• Добавить Read разрешения для Domain\Test на C:\TEST.
• Обновите браузер и посмотрите, как пользователь снова может увидеть Index.html.

Вопрос:

Несмотря на то, что пул приложений был изменен для запуска под учетной записью пользователя домена, почему сайт все еще может получить доступ к файлам веб-сайта, когда разрешения были предоставлены только встроенному ApplicationPoolIdentity (IIS AppPool\TEST) как наблюдается в сценарии 3?

Я ожидаю, что сценарий 3 потерпит неудачу, и только сценарий 5 будет работать.