Windows 10, IIS 10: доступ к файлам, часть 6 (тест 2 и выводы)
Начало:
1. Windows 10, IIS 10: доступ к файлам, часть 1 (основы, термины)
2. Windows 10, IIS 10: доступ к файлам, часть 2 (архитектура IIS)
3. Windows 10, IIS 10: доступ к файлам, часть 3 (IUSR и IIS_IUSRS)
4. Windows 10, IIS 10: доступ к файлам, часть 4 (как менять доступ)
5. Windows 10, IIS 10: доступ к файлам, часть 5 (тест 1 и выводы)
Тест 2. Доступ к файлам и папкам динамического сайта, если предполагается, что скрипты сайта должны иметь право на создание и/или изменение файлов на веб-сервере.
Чтобы смоделировать эту ситуацию, я создал в папке сайта «Default Web Site» файл «modfile.php» и тестовую папку «testFolder». Содержимое файла «modfile.php»:
Код, показанный в блоке выше, записывает строку «Илья» в файл «test.txt», находящийся в папке «testFolder», которая, в свою очередь, находится в той же папке, что и скрипт «modfile.php». Если файл «test.txt» в папке «testFolder» не существует, он будет создан. Если файл «test.txt» в папке «testFolder» существует, его содержимое будет затерто строкой «Илья». Подробнее об использованной в коде функции можно прочесть в статье «file_put_contents» руководства по языку PHP.
Отмечу, что название файла 'testFolder\test.txt' указано в одинарных кавычках потому, что при таком определении строки символ обратной косой черты не будет в данном случае интерпретирован как экранирующий символ. Например, если указать это же название файла в двойных кавычках "testFolder\test.txt", то последовательность символов \t будет интерпретирована как символ горизонтальной табуляции. В данном случае нам это не нужно. Тут об этом подробнее.
Список управления доступом к файлу «modfile.php» перед началом теста:
C:\inetpub\wwwroot\modfile.php
Владелец: Администраторы
Список управления доступом:
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
В принципе, от файла «modfile.php» нам нужно только то, чтобы пользователь нашего сайта, обратившись через свой браузер к этому файлу, смог бы его запустить (имел бы на это право). То есть список управления доступом к этому файлу ничем не должен отличаться от списка управления доступом к файлу «phpinfo.php», который я тестировал ранее в тесте 1. Таким образом, при дальнейшем тестировании я не буду менять вышеописанный список управления доступом для файла «modfile.php».
Список управления доступом к папке «testFolder» перед началом теста:
2.1.
C:\inetpub\wwwroot\testFolder\
Владелец: Администраторы
Список управления доступом:
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Полный доступ
Пока что у списка управления доступом к папке «testFolder» нет принципиальных отличий от списка управления доступом к файлу «modfile.php».
Откроем файл «modfile.php» из браузера по URL-адресу «localhost/modfile.php» от разных встроенных учетных записей так, как мы это делали в тесте 1. В результате и для учетной записи IUSR, и для учетной записи «DefaultAppPool» я получил одну и ту же ошибку:
PHP Warning: file_put_contents(testFolder\test.txt): Failed to open stream: Permission denied in C:\inetpub\wwwroot\modfile.php on line 1
Хоть в этом сообщении упомянут файл «modfile.php» (потому что ошибка случилась при выполнении программы из этого скрипта), но проблема не в нем, а в том, что не хватает прав доступа для создания/изменения файла «test.txt» в папке «testFolder».
Почему не хватает прав доступа? Потому что в списке управления доступом к папке «testFolder» группе «Пользователи», в которую автоматически входят учетные записи IUSR и «DefaultAppPool», и группе «IIS_IUSRS», в которую автоматически входит учетная запись «DefaultAppPool», предоставлено лишь право на «Чтение и выполнение» и только (не предоставлено право на создание/изменение файлов).
Технически, конечно, возможно для этих групп в указанном списке управления доступом подправить доступ так, как нам нужно. Однако, я не хочу менять права доступа для групп, потому что таким образом неконтролируемо (что небезопасно) расширяется доступ и для других пользователей, которые входят в эти группы на данный момент или могут войти туда в будущем. Думаю, правильнее с точки зрения безопасности включить в указанный список управления доступом элемент, дающий нужное право доступа именно нужному пользователю.
Попробуем дать полный доступ к папке «testFolder» встроенному пользователю IUSR:
2.2.
C:\inetpub\wwwroot\testFolder\
Владелец: Администраторы
Список управления доступом:
IUSR Полный доступ
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Полный доступ
Откроем файл «modfile.php» из браузера по URL-адресу «localhost/modfile.php» от разных встроенных учетных записей. В результате и для учетной записи IUSR, и для учетной записи «DefaultAppPool» я получил ту же самую ошибку, что и ранее для подтеста 2.1.
Удалим из списка управления доступом к папке «testFolder» внесенный туда ранее элемент доступа для пользователя IUSR и дадим полный доступ пользователю «DefaultAppPool»:
2.3.
C:\inetpub\wwwroot\testFolder\
Владелец: Администраторы
Список управления доступом:
DefaultAppPool Полный доступ
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Полный доступ
Откроем файл «modfile.php» из браузера по URL-адресу «localhost/modfile.php» от учетной записи IUSR и отдельно от учетной записи «DefaultAppPool». В этот раз для обеих этих учетных записей скрипт «modfile.php» выполнился успешно (без ошибки), файл «test.txt» был успешно создан/изменен в папке «testFolder».
Выводы по тесту 2.
Если планируется хостить на сервере динамический сайт (веб-приложение) под управлением веб-сервера IIS 10 и при этом предполагается, что скрипты динамического сайта должны создавать и/или изменять файлы на сервере (к примеру, веб-приложение «WordPress»), то для этого умолчательные настройки веб-сервера IIS 10 могут подойти, но при этом потребуется правильно настроить доступ к файлам и папкам сайта.
Для этого к папке, в которой будут создаваться/изменяться файлы, можно предоставить полный доступ учетной записи соответствующего пула приложений (в моем случае это учетная запись «DefaultAppPool»). В случае веб-приложения «WordPress», по идее, можно предоставить полный доступ учетной записи пула приложений к корневой папке веб-приложения «WordPress» с включенным наследованием этого права для вложенных файлов и папок (такое наследование включается по умолчанию при добавлении элемента в список управления доступом).
Технически можно вместо полного доступа учетной записи пула приложений предоставить полный доступ группам, в которые входит эта учетная запись, то есть либо группе «Пользователи», либо группе «IIS_IUSRS». Но мне этот способ кажется менее безопасным, чем с предоставлением полного доступа учетной записи пула приложений. Причины я описал выше при тестировании.
Почему в данном случае не подходит предоставление полного доступа учетной записи IUSR (см. подтест 2.2 выше)? Насколько я понимаю, при создании/изменении файла на сервере скриптом «modfile.php» считается, что это действует не пользователь (посетитель) нашего сайта, а скрипт сайта, то есть исполняемый файл «php-cgi.exe», который действует от имени учетной записи пула приложений (в моем случае от имени учетной записи «DefaultAppPool»). Подробнее об архитектуре веб-сервера IIS я писал в отдельном посте.
* * *
Как предоставить полный доступ учетной записи пула приложений (в моем случае это «DefaultAppPool») к целевой папке (в моем случае это «testFolder»)?
1. Откроем свойства целевой папки и перейдем на вкладку «Безопасность».
2. Нажмем на кнопку «Изменить...»:
3. В открывшемся окне нажмем на кнопку «Добавить...» (см. иллюстрацию выше).
4. В открывшемся окне в поле «Введите имена выбираемых объектов» следует ввести строку «IIS AppPool\DefaultAppPool» (вместо «DefaultAppPool» тут следует вставить имя вашего пула приложений, у меня это и есть «DefaultAppPool»). Если ввести просто имя пула приложений, то оно найдено не будет, поэтому приходится сначала вводить текст «IIS AppPool\», чтобы операционная система смогла разобраться. См. иллюстрацию ниже:
5. После ввода текста из пункта 4 можно нажать на кнопку «OK» (или предварительно еще нажать на кнопку «Проверить имена», но это необязательно) и пользователь «DefaultAppPool» будет добавлен в список управления доступом целевой папки, а это вспомогательное окно, предназначенное для поиска и выбора субъектов безопасности, закроется.
6. По умолчанию пользователю «DefaultAppPool» дают только права на «Чтение и выполнение». Назначим ему «Полный доступ», установив соответствующую галку в списке разрешений:
7. После этого нажмем на кнопку «OK» внизу окна, окно закроется. И нажмем еще раз на кнопку «ОК» в самом первом окне, оно тоже закроется. На этом всё. Этот способ описан в документации на сайте компании «Microsoft».
То же самое можно сделать, выбрав в на самой первой иллюстрации кнопку «Дополнительно». Там это делается несколько по-другому, но разобраться несложно.
Полезная ссылка:
https://stackoverflow.com/questions/14934006/iis-iusrs-and-iusr-permissions-in-iis8
1. Windows 10, IIS 10: доступ к файлам, часть 1 (основы, термины)
2. Windows 10, IIS 10: доступ к файлам, часть 2 (архитектура IIS)
3. Windows 10, IIS 10: доступ к файлам, часть 3 (IUSR и IIS_IUSRS)
4. Windows 10, IIS 10: доступ к файлам, часть 4 (как менять доступ)
5. Windows 10, IIS 10: доступ к файлам, часть 5 (тест 1 и выводы)
Тест 2. Доступ к файлам и папкам динамического сайта, если предполагается, что скрипты сайта должны иметь право на создание и/или изменение файлов на веб-сервере.
Чтобы смоделировать эту ситуацию, я создал в папке сайта «Default Web Site» файл «modfile.php» и тестовую папку «testFolder». Содержимое файла «modfile.php»:
Код, показанный в блоке выше, записывает строку «Илья» в файл «test.txt», находящийся в папке «testFolder», которая, в свою очередь, находится в той же папке, что и скрипт «modfile.php». Если файл «test.txt» в папке «testFolder» не существует, он будет создан. Если файл «test.txt» в папке «testFolder» существует, его содержимое будет затерто строкой «Илья». Подробнее об использованной в коде функции можно прочесть в статье «file_put_contents» руководства по языку PHP.
Отмечу, что название файла 'testFolder\test.txt' указано в одинарных кавычках потому, что при таком определении строки символ обратной косой черты не будет в данном случае интерпретирован как экранирующий символ. Например, если указать это же название файла в двойных кавычках "testFolder\test.txt", то последовательность символов \t будет интерпретирована как символ горизонтальной табуляции. В данном случае нам это не нужно. Тут об этом подробнее.
Список управления доступом к файлу «modfile.php» перед началом теста:
C:\inetpub\wwwroot\modfile.php
Владелец: Администраторы
Список управления доступом:
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
В принципе, от файла «modfile.php» нам нужно только то, чтобы пользователь нашего сайта, обратившись через свой браузер к этому файлу, смог бы его запустить (имел бы на это право). То есть список управления доступом к этому файлу ничем не должен отличаться от списка управления доступом к файлу «phpinfo.php», который я тестировал ранее в тесте 1. Таким образом, при дальнейшем тестировании я не буду менять вышеописанный список управления доступом для файла «modfile.php».
Список управления доступом к папке «testFolder» перед началом теста:
2.1.
C:\inetpub\wwwroot\testFolder\
Владелец: Администраторы
Список управления доступом:
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Полный доступ
Пока что у списка управления доступом к папке «testFolder» нет принципиальных отличий от списка управления доступом к файлу «modfile.php».
Откроем файл «modfile.php» из браузера по URL-адресу «localhost/modfile.php» от разных встроенных учетных записей так, как мы это делали в тесте 1. В результате и для учетной записи IUSR, и для учетной записи «DefaultAppPool» я получил одну и ту же ошибку:
PHP Warning: file_put_contents(testFolder\test.txt): Failed to open stream: Permission denied in C:\inetpub\wwwroot\modfile.php on line 1
Хоть в этом сообщении упомянут файл «modfile.php» (потому что ошибка случилась при выполнении программы из этого скрипта), но проблема не в нем, а в том, что не хватает прав доступа для создания/изменения файла «test.txt» в папке «testFolder».
Почему не хватает прав доступа? Потому что в списке управления доступом к папке «testFolder» группе «Пользователи», в которую автоматически входят учетные записи IUSR и «DefaultAppPool», и группе «IIS_IUSRS», в которую автоматически входит учетная запись «DefaultAppPool», предоставлено лишь право на «Чтение и выполнение» и только (не предоставлено право на создание/изменение файлов).
Технически, конечно, возможно для этих групп в указанном списке управления доступом подправить доступ так, как нам нужно. Однако, я не хочу менять права доступа для групп, потому что таким образом неконтролируемо (что небезопасно) расширяется доступ и для других пользователей, которые входят в эти группы на данный момент или могут войти туда в будущем. Думаю, правильнее с точки зрения безопасности включить в указанный список управления доступом элемент, дающий нужное право доступа именно нужному пользователю.
Попробуем дать полный доступ к папке «testFolder» встроенному пользователю IUSR:
2.2.
C:\inetpub\wwwroot\testFolder\
Владелец: Администраторы
Список управления доступом:
IUSR Полный доступ
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Полный доступ
Откроем файл «modfile.php» из браузера по URL-адресу «localhost/modfile.php» от разных встроенных учетных записей. В результате и для учетной записи IUSR, и для учетной записи «DefaultAppPool» я получил ту же самую ошибку, что и ранее для подтеста 2.1.
Удалим из списка управления доступом к папке «testFolder» внесенный туда ранее элемент доступа для пользователя IUSR и дадим полный доступ пользователю «DefaultAppPool»:
2.3.
C:\inetpub\wwwroot\testFolder\
Владелец: Администраторы
Список управления доступом:
DefaultAppPool Полный доступ
IIS_IUSRS Чтение и выполнение
TrustedInstaller Полный доступ
СИСТЕМА Полный доступ
Администраторы Полный доступ
Пользователи Чтение и выполнение
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Полный доступ
Откроем файл «modfile.php» из браузера по URL-адресу «localhost/modfile.php» от учетной записи IUSR и отдельно от учетной записи «DefaultAppPool». В этот раз для обеих этих учетных записей скрипт «modfile.php» выполнился успешно (без ошибки), файл «test.txt» был успешно создан/изменен в папке «testFolder».
Выводы по тесту 2.
Если планируется хостить на сервере динамический сайт (веб-приложение) под управлением веб-сервера IIS 10 и при этом предполагается, что скрипты динамического сайта должны создавать и/или изменять файлы на сервере (к примеру, веб-приложение «WordPress»), то для этого умолчательные настройки веб-сервера IIS 10 могут подойти, но при этом потребуется правильно настроить доступ к файлам и папкам сайта.
Для этого к папке, в которой будут создаваться/изменяться файлы, можно предоставить полный доступ учетной записи соответствующего пула приложений (в моем случае это учетная запись «DefaultAppPool»). В случае веб-приложения «WordPress», по идее, можно предоставить полный доступ учетной записи пула приложений к корневой папке веб-приложения «WordPress» с включенным наследованием этого права для вложенных файлов и папок (такое наследование включается по умолчанию при добавлении элемента в список управления доступом).
Технически можно вместо полного доступа учетной записи пула приложений предоставить полный доступ группам, в которые входит эта учетная запись, то есть либо группе «Пользователи», либо группе «IIS_IUSRS». Но мне этот способ кажется менее безопасным, чем с предоставлением полного доступа учетной записи пула приложений. Причины я описал выше при тестировании.
Почему в данном случае не подходит предоставление полного доступа учетной записи IUSR (см. подтест 2.2 выше)? Насколько я понимаю, при создании/изменении файла на сервере скриптом «modfile.php» считается, что это действует не пользователь (посетитель) нашего сайта, а скрипт сайта, то есть исполняемый файл «php-cgi.exe», который действует от имени учетной записи пула приложений (в моем случае от имени учетной записи «DefaultAppPool»). Подробнее об архитектуре веб-сервера IIS я писал в отдельном посте.
* * *
Как предоставить полный доступ учетной записи пула приложений (в моем случае это «DefaultAppPool») к целевой папке (в моем случае это «testFolder»)?
1. Откроем свойства целевой папки и перейдем на вкладку «Безопасность».
2. Нажмем на кнопку «Изменить...»:
3. В открывшемся окне нажмем на кнопку «Добавить...» (см. иллюстрацию выше).
4. В открывшемся окне в поле «Введите имена выбираемых объектов» следует ввести строку «IIS AppPool\DefaultAppPool» (вместо «DefaultAppPool» тут следует вставить имя вашего пула приложений, у меня это и есть «DefaultAppPool»). Если ввести просто имя пула приложений, то оно найдено не будет, поэтому приходится сначала вводить текст «IIS AppPool\», чтобы операционная система смогла разобраться. См. иллюстрацию ниже:
5. После ввода текста из пункта 4 можно нажать на кнопку «OK» (или предварительно еще нажать на кнопку «Проверить имена», но это необязательно) и пользователь «DefaultAppPool» будет добавлен в список управления доступом целевой папки, а это вспомогательное окно, предназначенное для поиска и выбора субъектов безопасности, закроется.
6. По умолчанию пользователю «DefaultAppPool» дают только права на «Чтение и выполнение». Назначим ему «Полный доступ», установив соответствующую галку в списке разрешений:
7. После этого нажмем на кнопку «OK» внизу окна, окно закроется. И нажмем еще раз на кнопку «ОК» в самом первом окне, оно тоже закроется. На этом всё. Этот способ описан в документации на сайте компании «Microsoft».
То же самое можно сделать, выбрав в на самой первой иллюстрации кнопку «Дополнительно». Там это делается несколько по-другому, но разобраться несложно.
Полезная ссылка:
https://stackoverflow.com/questions/14934006/iis-iusrs-and-iusr-permissions-in-iis8