headermask image
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

NTFS и подводные камни

В последнее время замечаю такую тенденцию, что пользователи и системные администраторы не совсем понимают механизм работы NTFS и понятия как “Действующие разрешения”. Непонимание этого вопроса приводит к тому, что при выдаче прав на некий ресурс пользователю реальные права самого пользователя оказываются не совсем такими, как этого ожидал администратор.

Итак, я попробую разъяснить некоторые подводные камни при назначении прав Full Control пользователям и назначения прав на уровне файлов.

Доподлинно известно, что право доступа на ресурс (файл/папка) определяется ACL самого ресурса. Однако, это не совем верно. Разберём типичный случай:

Проблема:

Имеется папка, скажем, Folder1 и пользователю JohnSmith назначаются на неё право Full Control. При этом пользователь JohnSmith будет иметь права Full Control как на эту папку, так и на все вложенные подпапки и файлы. Но, если администратор захочет на вложенный файл File дать право Read/Execute. Т.к. права доступа к ресурсу определяются самим ресурсом, то можно предположить, что пользователь JohnSmith будет иметь право Full Control на всю папку Folder1 и все её подпапки, кроме файла File1. В этом можно смело убедиться, если посмотреть вкладку Effective Permissions в дополнительных свойствах безопасности файла. Однако, приходит JohnSmith и спокойно удаляет файл. Резонный вопрос, “почему так? Ведь Effective Permissions показывает, что у пользователя права Только чтение!”. Вот тут необходимо уловить одну тонкость:

  • право удаления файла появляется не от разрешений самого файла, а родительской папки.

Дело в том, что при удалении файла NTFS не берёт в расчёт разрешения самого файла, а смотрит право родительской папки для этого файла. А если посмотреть свойства родительской папки, то там будет отмечено разрешение Delete subfolders and files. При этом не важно, наследует ли файл разрешения от родителькой папки, или нет. Именно право Delete subfolders and files перекрывает право самого файла (Read) и позволяет удалить этот файл.

Решение проблемы:

Очень многие спотыкаются на эти грабли, поэтому для эффективного, а главное, гарантированного назначения прав пользователю следует руководствоваться следующими правилами:

  • не задавать права на ресурсы на уровне файлов, а только на уровне папок;
  • не давать пользователям права Full Control на папку, а только Modify;
  • Создавать иерархию разрешений в виде ёлочки. Т.е. увеличивая права пользователя на ресурс спускаясь по дереву. Иными словами “наименьшие права на корень ресурса и расширять права уже на дочерние ресурсы.

Во втором пункте отмечено Modify. Почему Modify, если это по сути равно Full Control? Дело в том, что право Modify не содержит права Delete subfolders and files, а значит, что при правах чтения на файл пользователь уже не сможет его удалить.

Проблема:

Схожий случай. Имеется папка Folder1, на которую пользователи JohnSmith и MikeJohnson имеют право Full Control. В этой папке JohnSmith создал свой файл. Файл может наследовать права, а может и не наследовать права от родительской папки (вобщем, без разницы). Но по некоторым причинам администратору потребовалось временно запретить доступ к файлу для пользователя MikeJohnson. Но при этом оставить права Full Control для остальных ресурсов в папке Folder1. Что самое вероятное сделает администратор? Как показывает практика, то администратор выставит на файле Deny Full Control для пользователя MikeJohnson. При этом будет запрещён доступ к файлу у MikeJohnson и задача по сути решена. Но опираясь на предыдущий пример при наличии прав Full Control пользователь сможет его удалить, хотя из-за запрета Deny просмотреть содержимое файла не сможет (а перехватить владение ему не даст политика). А если просмотреть Effective Permissions для пользователя MikeJohnson, то увидим, что прав он никаких не имеет на файл. Но, пользуясь правом Delete subfolders and files, которое перекроет явный запрет от родительской папки удаление возможно. И тут даже не спасает _явный_ запрет любого доступа к файлу.

Решение:

решение данной ситуации (точнее её избежание) будет основываться на следующих правилах:

  • не задавать права на ресурсы на уровне файлов, а только на уровне папок;
  • не давать пользователям права Full Control на папку, а только Modify;
  • не использовать явный запрет Deny для ресурсов без чёткого понимания работы разрешений NTFS;
  • отменять какой-либо вид доступа только путём отнятия явного/унаследованного разрешения на действие.Обе эти ситуации можно смоделировать и получите результат, который я описал. Одно дело моделирование в тестовой среде, а другое дело, когда администраторы _сознательно_ так делают на производстве, а потом на форумах обвиняют Microsoft в кривом NTFS, не разобравшись в принципе его работы. Действительно, разрешения NTFS – очень серьёзная и обширная тема, которой, увы, системные администраторы не всегда уделяют должного внимания.Для интересующихся могу подкинуть две задачки по второй проблеме, а так же просто подумать на досуге, о том, что не всё так просто как кажется.А именно:
    1. а теперь найдите где-нибудь удалённый пользователем файл.
    2. Представьте, что MikeJohnson сам создал в папке файл и администратор задал для файла Deny Full Control пользователю MikeJohnson. Т.е. аналогичная ситуация, кроме факта, что пользователю закрыли доступ на файл, который он создал сам. При попытке удалить файл у него уже не срабатывает право Delete subfolders and files, хотя оно есть. Но пока пользователь не уберёт запрет с файла, удалить его не сможет.
  • Оригинал статьи здесь.

    Похожие посты
  • Как происходит фрагментация файлов в операционных системах Windows XP/Windows Server 2003
  • Контроль доступа к ресурсам
  • Разрешения файловой системы
  • Инструменты управления хранением и общим доступом Windows 2008
  • Домашние каталоги пользователей в Windows Server 2003 R2
  • Подключение Windows 7 к iSCSI SAN
  • Использование iSCSI на Debian Lenny (Initiator и Target)
  • Восстановить данные легче, чем удалить их навсегда
  • Microsoft Forefront TMG – функции резервного копирования и восстановления
  • Резервирование реестра и системных параметров.