Файл ASP.NET, созданный одним пулом приложений, недоступен для чтения из другого

У меня есть два приложения ASP.NET, настроенных на доступ для чтения / записи к общему местоположению NAS, которое они используют в качестве простого хранилища файлов с ключом.

] Расположение NAS отображается локально для каждого приложения с помощью соединений каталогов NTFS, например:

C:\inetpub\App1\Content\files
C:\inetpub\App2\Content\files

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

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

После изучения атрибутов безопасности файлов, созданных обоими приложениями, я заметил, что все вновь созданные файлы из любого приложения демонстрируют следующую аномалию:

  • Учетной записи IIS_IUSRS не предоставлено НИ ОДНОГО из разрешений для файла
  • неявной учетной записи IIS AppPool \ App # предоставлены ВСЕ разрешения.

Поскольку каждое приложение работает под собственной учетной записью IIS AppPool \ App #, это эффективно предотвращает их чтение любых файлов, кроме тех, которые они создали сами.

Фактический код, создающий файлы, идентичен в обоих приложениях и не делает ничего особенного, кроме:

  1. создание нового подкаталога в общем корне и присвоение ему уникального имени
  2. создание файла в этом подкаталоге с помощью объекта .NET System.IO.FileStream с использованием всех параметров по умолчанию.

Что меня озадачивает, так это тот факт, что IIS_IUSRS включен в число учетных записей с доступом, но не имеет всех базовых разрешений, хотя родительская и корневая папки настроены на включение разрешений на чтение и запись в «Эта папка, подпапки и файлы».

Что я упустил и как решить эту проблему?

0
задан 10 August 2017 в 12:19
1 ответ

Мне удалось решить проблему, просто добавив разрешения для обеих известных учетных записей IIS AppPool \ App # в корневой каталог, в который монтируется NAS. Обратной стороной этого подхода является то, что любой дополнительный пул приложений в будущем также придется обрабатывать вручную.

0
ответ дан 24 November 2019 в 04:04

Теги

Похожие вопросы