NT club. Часть 16. Списки контроля доступа
NT club. Часть 16. Списки контроля доступа
— Желтые штаны — два раза "ку"... Ку, ку...
(с) "Кин-Дза-Дза!"
Введение
После затяжного перерыва возобновляем работу нашего клуба. Как я и обещал, продолжим изучение подсистемы безопасности NT. На этот раз мы остановимся на одном из концептуальных понятий — списке контроля доступа, а также рассмотрим его применение касательно объектов реестра и файловой системы (с чем большинство пользователей и сталкивается на практике). Под файловой системой я, естественно, понимаю "родную" для NT NTFS. Поехали!
Теория
Любая серьезная многопользовательская ОС предусматривает разграничение доступа к объектам для пользователей и их группам. Под объектом здесь подразумевается не только объект в каноническом его значении (т.е. что-то закрытое, самодостаточное), но и любой разделяемый ресурс. Скажем, этим ресурсом может быть файл, именованный канал, синхронизирующая структура ядра ОС, процесс, поток, служба и т.д. (не будем углубляться в дебри системного программирования). Для Windows NT все разделяемые, защищаемые и именованные структуры являются истинными объектами, т.е. содержат, кроме самих данных, и код по их обработке — методы, чем достигается независимость внутренней реализации объекта от внешнего интерфейса. Это позволяет также легко вести учет ссылок на конкретный экземпляр объекта. К слову, ряд структур, используемых только отдельными компонентами ядра, объектами не являются, так как они не должны соответствовать приведенным выше требованиям.
Итак, мы знаем, что у нас есть разнообразные объекты, а также пользователи, которые должны в зависимости от своих прав получить или не получить доступ к конкретному объекту. В общих чертах данный процесс выглядит так. Пользователь при входе в систему вводит свое имя и пароль, тем самым производя аутентификацию. Проверяющая подсистема ОС сверяет полученные данные с имеющимися в ее базе. Если они одинаковы, значит, это "свой", впускаем, нет — "пшел вон!" Если процесс аутентификации прошел успешно, запускается первый процесс (программа) сессии данного пользователя (здесь идет серьезное обобщение, впрочем, для нас это не важно), создающий рабочую среду (оболочку и т.д.). Этот процесс получает контекст защиты (так называемый маркер доступа), который идентифицирует пользователя, его группы и привилегии процесса. Все созданные пользователем процессы (т.е. открытые программы) запускаются либо от имени этого процесса, либо его дочерних, что не важно, так как любой процесс получает маркер доступа своего родителя. В итоге ОС может теперь понять, какая программа кем запущена и какие у нее права.
Однако остается еще одна проблема: при обращении программы (процесса) к объекту ОС должна с чем-то сравнить ее маркер доступа для решения вопроса о разрешении/запрещении доступа (это действие называется авторизацией). В разных системах такая структура данных для различных объектов реализована по-разному (в NT она называется дескриптором защиты). Например, в большинстве файловых систем для UNIX каталоги и файлы имеют структуры защиты, состоящие из имени владельца, его группы и группы "остальные", которым соответствует числовое значение, определяющее права доступа. Такая система довольно проста, но не отличается гибкостью, поэтому ведутся разработки для переноса на некоторые ФС технологии списков контроля доступа. В то же время, в других ОС (и NT в том числе) все объекты имеют одинаковую структуру, отвечающую за их защиту — уже упомянутый список контроля доступа. Что же это такое, и чем оно отличается (в положительную сторону) от других методов защиты?
Собственно, разительных отличий нет. И там, и там что-то с чем-то сверяется (этим озабочена та часть ядра, которая отвечает за безопасность — справочный монитор безопасности для NT), а потом выдается либо разрешение на доступ, либо запрет. Однако достоинство списков контроля (управления) доступа (Access Control List, ACL) в их гибкости, т.е. можно очень точно разграничить права, а также в единообразности и универсальности (научился использовать их для файлов, разберешься и для всего остального).
Рассмотрим теперь, что представляет собой дескриптор защиты. Если не углубляться в подробности, то он состоит из следующих основных компонентов:
• Номер версии защиты.
• Флаги (необязательно).
• SID владельца.
• SID группы.
• Список управления избирательным доступом (Discretionary Access Control List, DACL).
• Системный список управления доступом (System Access Control List, SACL).
Теперь поясним, что каждый элемент означает. Итак, с номером защиты и с флагами, думаю, все понятно; нам они, собственно, и неинтересны. А что такое SID владельца? Дело в том, что все объекты, выполняющие в системе какие-нибудь действия (например, пользователи и группы), кроме имени, имеют свой идентификатор защиты (Security Identifier, SID). Именно по нему ОС идентифицирует объект (вспомните содержимое папки RECYCLER, названия вложенных папок — идентификаторы защиты пользователя), что позволяет избежать проблем при повторении имен. Сам идентификатор представляет собой числовое значение переменной длины, формирующееся по правилам, нас здесь не касающимся:-). В итоге в дескрипторе защиты объекта уже содержится имя его владельца (точнее, его SID). С SID группы аналогично — это идентификатор основной группы владельца (используется только подсистемой POSIX).
А теперь самое вкусное: DACL и SACL. По сути дела, это разновидности ACL. Первый служит для указания прав доступа к объекту для конкретных пользователей и групп (в том числе и встроенных). Второй ответственен за ведение аудита в журнале безопасности соответствующих действий над объектом для указанных пользователей/групп (используется только для файловой системы и реестра). Любой ACL состоит, кроме заголовка, из вхождений (элементов) контроля доступа (Access Control Entries, ACE).
ACE для DACL состоит из SID пользователя/группы и маски доступа, разной для разных типов объектов, а также флагов, отвечающих за наследование. Объекты могут быть контейнерами либо листьями. Контейнеры могут содержать другие контейнеры и/или листья и так далее. ACE бывают двух общих видов (особенности Active Directory не рассматриваем): "доступ разрешен" и "доступ отклонен" (позже я это докажу вам на примере). Причем сначала идут запрещающие ACE, а потом разрешающие (это очень важно: в обратном случае редактор DACL файловой системы, например, сочтет это ошибкой и предложит вам унаследовать DACL родителя, хотя это случается архиредко и связано с использованием устаревших функций Win32).
SACL состоит из ACE двух типов: системного аудита (System Audit ACE) и объекта системного аудита (System Audit Object ACE). Они обеспечивают аудит указанных действий для выбранных пользователей, причем может записываться как "успех", так и "отказ". В плане наследования SACL аналогичен DACL. Если SACL не существует, аудит не ведется.
Алгоритмы
От общей теории перейдем к рассмотрению алгоритмов работы ACL:
1. Если DACL не существует (null), то все имеют полный доступ (именно с этой точки зрения можно смотреть на FAT).
2. Если DACL пустой, то никто не имеет доступа.
3. Если вызываемый процесс (точнее, поток, но это нам не важно) имеет право на захват объекта во владение, то он может стать владельцем объекта и изменить DACL.
4. Если вызываемый процесс является владельцем, то он может изменить DACL.
5. Из маски прав доступа удаляется маска доступа каждого ACE типа "доступ отклонен", если SID совпадает с SID маркера доступа процесса.
6. К полученной маске прав доступа добавляется маска доступа каждого ACE типа "доступ разрешен", если SID совпадает с SID маркера доступа процесса (не считая тех прав, в которых уже отказано).
7. Полученная маска доступа и определяет права доступа, которые имеет программа, их запрашивающая (точнее, пользователь, ее запустивший — SID-то его).
Это общая схема, тем не менее, дающая нам возможность понять, как все это работает. Теперь подобьем наши знания и добавим новые:
• Владелец объекта (по умолчанию его создатель) способен делать с ним все что угодно, так как может изменить DACL (да и SACL тоже).
• Пользователь, который имеет права на вступление во владение (администратор, например), способен стать его владельцем со всеми вытекающими...
• Если права для пользователя или группы не указаны, то они не имеют доступа к объекту.
• Права имеют кумулятивный характер, т.е. наследуются пользователями конкретной группы. Если, скажем, группа Все имеет полный доступ к какому-либо объекту, то и все члены этой группы тоже имеют полный доступ.
• Запрет имеет большие привилегии, чем разрешение. Кажется, зачем это надо, ведь можно просто не указать разрешение? А если мне нужно, чтобы конкретный пользователь группы не имел доступа к объекту, а вся группа имела? Не удалять же его из группы:-)!
• По умолчанию созданный (или скопированный) объект наследует права доступа (DACL, а также SACL) от родительского контейнера, но это можно изменить. При наследовании ACE удалить невозможно, но можно добавить.
• При необходимости можно распространить DACL (и SACL) на все вложенные контейнеры и объекты, тем самым заменив их права.
Будем помнить эти несложные правила. Что ж, я, наверное, утомил читателя пространными рассуждениями о принципах строения и работы ACL. Перейдем к более интересной и полезной практической работе. Перед этим, однако, я настаиваю на том, чтобы вы еще раз прочитали раздел Алгоритмы — это основополагающие сведения.
Практика
Как и говорилось, экспериментировать мы будем над ФС и реестром (в систему встроен графический редактор ACL и консольная версия редактора DACL — cacls.exe). В первую очередь, потому, что это актуально для пользователя, а во вторую — что здесь применяются все возможности ACL (включая наследование). В качестве ОС выбрана русская версия Windows XP Professional. Для начала в Windows XP необходимо отключить опцию Использовать простой общий доступ к файлам из закладки Вид окна Свойства папки Панели управления. Данный режим предназначен для неподготовленных пользователей и весьма ограничен в возможностях. В Windows XP Home Edition вам это сделать не удастся, поэтому нужно будет либо работать в Безопасном режиме (Safe Mode), либо воспользоваться консольной утилитой cacls.exe (или ее расширенным аналогом из Support Tools — xcacls.exe).
Итак, сначала откроем редактор ACL. Для файловой системы достаточно в Проводнике в контекстном меню выбрать пункт Свойства, а затем закладку Безопасность (для папок можно сразу выбрать пункт Общий доступ и безопасность...). Для реестра выбираем нужную ветвь (разграничение доступа идет только на ветви, а не отдельные ключи) и в контекстном меню выбираем пункт Разрешения... (для пользователей Windows NT и 2000 придется воспользоваться программой regedt32.exe, так как только она обладает нужной функциональностью). Так как в обоих случаях используется один и тот же редактор ACL и общие принципы, то продолжать я буду на примере свойств папки.
Проделав указанные действия, вы увидите следующее окно (см. рис. 1):
На нем перечислены пользователи и их права. Можно добавлять новых и удалять уже имеющихся (если позволяет наследование). Однако это лишь вершина айсберга — здесь перечислены только общие типы доступа, основанные на нескольких ACE с одинаковым SID. Проверим? Жмем кнопку Дополнительно и оказываемся в настоящем редакторе ACL (см.
рис. 2).
Как видим, тут перечислены все ACE, причем сначала идут запрещающие. Мы можем добавить, удалить и изменить ACE. При добавлении нас спросят об имени пользователя (см. рис. 3), которое можно ввести вручную либо воспользоваться поиском, нажав в появившемся окне Дополнительно, Поиск. Кнопка Типы объектов позволяет указать, что мы ищем: пользователей, группы или встроенных пользователей/группы. Кстати, имя имеет вид Имя контейнера (компьютера в нашем случае)\Имя пользователя, хотя можно просто вводить имя пользователя. С удалением все понятно, а редактирование представляет некоторый интерес.
Если обратить свое внимание на рис. 4, то можно увидеть, что мы вправе менять такие параметры, как имя пользователя (т.е. выбрали редактировать одно, а потом взяли да и сменили), параметры наследования (вложенные папки, объекты и т.д.), ограничение наследования (галочка внизу, становится доступна, когда выбрано наследование для подпапок и файлов) и собственно сами права. Кнопка Очистить выполняет быструю очистку всех галочек в ACE. Если мы поставим сразу запрещающие и разрешающие галочки, то будет создано два ACE: запрещающее и разрешающее (помните о примере). Причем этого можно добиться также и в самом первом окне (до нажатия кнопки Дополнительно) редактированием базовых типов доступа. Думаю, с этим разобрались.
Теперь опять посмотрим на рис. 2. Внизу можно заметить две галочки, отвечающие за наследование. Первая указывает на то, что данный объект наследует права доступа от родительского. Если снять эту галочку, то нам предложат либо скопировать унаследованные права в качестве заданных явно (что в большинстве случаев удобно), либо просто очистить ACL, если нет других ACE, кроме унаследованных. Вторая галочка позволяет заменить разрешения всех объектов и контейнеров заданными здесь, то есть по сути дела заставляет их наследовать права.
Что касается аудита — все абсолютно аналогично рассмотренному DACL включая наследование.
Перейдем к владению (закладка Владелец). По умолчанию владельцем является его создатель, т.е. пользователь либо группа. Однако можно вступить во владение объектом, если вы обладаете таким правом (по умолчанию им обладают члены группы Администраторы) либо если в DACL явно указано, что вы можете изменить владельца. Мы просто выбираем доступного пользователя или группу для владения, если надо, ставим галочку Заменить владельца субконтейнеров и объектов и жмем Применить. Все, объект наш:-).
Ну и напоследок бросим взгляд на закладку Действующие разрешения. Это полезное нововведение XP, позволяющее не просчитывать в уме права конкретного пользователя/группы. Достаточно выбрать имя, и мы получим список прав на основе имеющихся ACE.
Остается добавить, что внешний вид редактора ACL зависит от объекта, разрешения которого мы редактируем, т.е. могут быть недоступны какие-то опции. Если вам интересно, можете поэкспериментировать с консольными утилитами cacls.exe и xcacls.exe. Первая — аналог простого редактора базовых типов доступа, вторая позволяет работать с разрешениями более точно. Не забывайте, что, перетаскивая объект в другую папку в Проводнике, мы тем самым заставляем его унаследовать права этой папки. Чтобы этого не произошло, необходимо пользоваться консольными утилитами с соответствующими ключами либо файл-менеджерами, поддерживающими эту опцию (Total Commander, например).
Заключение
Надеюсь, приведенная мной информация оказалась вам полезной. Если это так, то я и дальше буду продолжать снабжать вас интересными фактами о системах семейства NT. В данной статье использовались материалы из книги Д. Соломона и М. Руссиновича "Внутреннее устройство Microsoft Windows 2000", а в предыдущей (забыл упомянуть) — книга Федора Зубанова "Microsoft Windows 2000. Планирование, развертывание, управление".
Конец.
Creator, creator_vom@tut.by
Рис. 1. Редактор ACL Рис. 2. Расширенный редактор ACL
Рис. 3. Выбор имени Рис. 4. Изменение ACE
— Желтые штаны — два раза "ку"... Ку, ку...
(с) "Кин-Дза-Дза!"
Введение
После затяжного перерыва возобновляем работу нашего клуба. Как я и обещал, продолжим изучение подсистемы безопасности NT. На этот раз мы остановимся на одном из концептуальных понятий — списке контроля доступа, а также рассмотрим его применение касательно объектов реестра и файловой системы (с чем большинство пользователей и сталкивается на практике). Под файловой системой я, естественно, понимаю "родную" для NT NTFS. Поехали!
Теория
Любая серьезная многопользовательская ОС предусматривает разграничение доступа к объектам для пользователей и их группам. Под объектом здесь подразумевается не только объект в каноническом его значении (т.е. что-то закрытое, самодостаточное), но и любой разделяемый ресурс. Скажем, этим ресурсом может быть файл, именованный канал, синхронизирующая структура ядра ОС, процесс, поток, служба и т.д. (не будем углубляться в дебри системного программирования). Для Windows NT все разделяемые, защищаемые и именованные структуры являются истинными объектами, т.е. содержат, кроме самих данных, и код по их обработке — методы, чем достигается независимость внутренней реализации объекта от внешнего интерфейса. Это позволяет также легко вести учет ссылок на конкретный экземпляр объекта. К слову, ряд структур, используемых только отдельными компонентами ядра, объектами не являются, так как они не должны соответствовать приведенным выше требованиям.
Итак, мы знаем, что у нас есть разнообразные объекты, а также пользователи, которые должны в зависимости от своих прав получить или не получить доступ к конкретному объекту. В общих чертах данный процесс выглядит так. Пользователь при входе в систему вводит свое имя и пароль, тем самым производя аутентификацию. Проверяющая подсистема ОС сверяет полученные данные с имеющимися в ее базе. Если они одинаковы, значит, это "свой", впускаем, нет — "пшел вон!" Если процесс аутентификации прошел успешно, запускается первый процесс (программа) сессии данного пользователя (здесь идет серьезное обобщение, впрочем, для нас это не важно), создающий рабочую среду (оболочку и т.д.). Этот процесс получает контекст защиты (так называемый маркер доступа), который идентифицирует пользователя, его группы и привилегии процесса. Все созданные пользователем процессы (т.е. открытые программы) запускаются либо от имени этого процесса, либо его дочерних, что не важно, так как любой процесс получает маркер доступа своего родителя. В итоге ОС может теперь понять, какая программа кем запущена и какие у нее права.
Однако остается еще одна проблема: при обращении программы (процесса) к объекту ОС должна с чем-то сравнить ее маркер доступа для решения вопроса о разрешении/запрещении доступа (это действие называется авторизацией). В разных системах такая структура данных для различных объектов реализована по-разному (в NT она называется дескриптором защиты). Например, в большинстве файловых систем для UNIX каталоги и файлы имеют структуры защиты, состоящие из имени владельца, его группы и группы "остальные", которым соответствует числовое значение, определяющее права доступа. Такая система довольно проста, но не отличается гибкостью, поэтому ведутся разработки для переноса на некоторые ФС технологии списков контроля доступа. В то же время, в других ОС (и NT в том числе) все объекты имеют одинаковую структуру, отвечающую за их защиту — уже упомянутый список контроля доступа. Что же это такое, и чем оно отличается (в положительную сторону) от других методов защиты?
Собственно, разительных отличий нет. И там, и там что-то с чем-то сверяется (этим озабочена та часть ядра, которая отвечает за безопасность — справочный монитор безопасности для NT), а потом выдается либо разрешение на доступ, либо запрет. Однако достоинство списков контроля (управления) доступа (Access Control List, ACL) в их гибкости, т.е. можно очень точно разграничить права, а также в единообразности и универсальности (научился использовать их для файлов, разберешься и для всего остального).
Рассмотрим теперь, что представляет собой дескриптор защиты. Если не углубляться в подробности, то он состоит из следующих основных компонентов:
• Номер версии защиты.
• Флаги (необязательно).
• SID владельца.
• SID группы.
• Список управления избирательным доступом (Discretionary Access Control List, DACL).
• Системный список управления доступом (System Access Control List, SACL).
Теперь поясним, что каждый элемент означает. Итак, с номером защиты и с флагами, думаю, все понятно; нам они, собственно, и неинтересны. А что такое SID владельца? Дело в том, что все объекты, выполняющие в системе какие-нибудь действия (например, пользователи и группы), кроме имени, имеют свой идентификатор защиты (Security Identifier, SID). Именно по нему ОС идентифицирует объект (вспомните содержимое папки RECYCLER, названия вложенных папок — идентификаторы защиты пользователя), что позволяет избежать проблем при повторении имен. Сам идентификатор представляет собой числовое значение переменной длины, формирующееся по правилам, нас здесь не касающимся:-). В итоге в дескрипторе защиты объекта уже содержится имя его владельца (точнее, его SID). С SID группы аналогично — это идентификатор основной группы владельца (используется только подсистемой POSIX).
А теперь самое вкусное: DACL и SACL. По сути дела, это разновидности ACL. Первый служит для указания прав доступа к объекту для конкретных пользователей и групп (в том числе и встроенных). Второй ответственен за ведение аудита в журнале безопасности соответствующих действий над объектом для указанных пользователей/групп (используется только для файловой системы и реестра). Любой ACL состоит, кроме заголовка, из вхождений (элементов) контроля доступа (Access Control Entries, ACE).
ACE для DACL состоит из SID пользователя/группы и маски доступа, разной для разных типов объектов, а также флагов, отвечающих за наследование. Объекты могут быть контейнерами либо листьями. Контейнеры могут содержать другие контейнеры и/или листья и так далее. ACE бывают двух общих видов (особенности Active Directory не рассматриваем): "доступ разрешен" и "доступ отклонен" (позже я это докажу вам на примере). Причем сначала идут запрещающие ACE, а потом разрешающие (это очень важно: в обратном случае редактор DACL файловой системы, например, сочтет это ошибкой и предложит вам унаследовать DACL родителя, хотя это случается архиредко и связано с использованием устаревших функций Win32).
SACL состоит из ACE двух типов: системного аудита (System Audit ACE) и объекта системного аудита (System Audit Object ACE). Они обеспечивают аудит указанных действий для выбранных пользователей, причем может записываться как "успех", так и "отказ". В плане наследования SACL аналогичен DACL. Если SACL не существует, аудит не ведется.
Алгоритмы
От общей теории перейдем к рассмотрению алгоритмов работы ACL:
1. Если DACL не существует (null), то все имеют полный доступ (именно с этой точки зрения можно смотреть на FAT).
2. Если DACL пустой, то никто не имеет доступа.
3. Если вызываемый процесс (точнее, поток, но это нам не важно) имеет право на захват объекта во владение, то он может стать владельцем объекта и изменить DACL.
4. Если вызываемый процесс является владельцем, то он может изменить DACL.
5. Из маски прав доступа удаляется маска доступа каждого ACE типа "доступ отклонен", если SID совпадает с SID маркера доступа процесса.
6. К полученной маске прав доступа добавляется маска доступа каждого ACE типа "доступ разрешен", если SID совпадает с SID маркера доступа процесса (не считая тех прав, в которых уже отказано).
7. Полученная маска доступа и определяет права доступа, которые имеет программа, их запрашивающая (точнее, пользователь, ее запустивший — SID-то его).
Это общая схема, тем не менее, дающая нам возможность понять, как все это работает. Теперь подобьем наши знания и добавим новые:
• Владелец объекта (по умолчанию его создатель) способен делать с ним все что угодно, так как может изменить DACL (да и SACL тоже).
• Пользователь, который имеет права на вступление во владение (администратор, например), способен стать его владельцем со всеми вытекающими...
• Если права для пользователя или группы не указаны, то они не имеют доступа к объекту.
• Права имеют кумулятивный характер, т.е. наследуются пользователями конкретной группы. Если, скажем, группа Все имеет полный доступ к какому-либо объекту, то и все члены этой группы тоже имеют полный доступ.
• Запрет имеет большие привилегии, чем разрешение. Кажется, зачем это надо, ведь можно просто не указать разрешение? А если мне нужно, чтобы конкретный пользователь группы не имел доступа к объекту, а вся группа имела? Не удалять же его из группы:-)!
• По умолчанию созданный (или скопированный) объект наследует права доступа (DACL, а также SACL) от родительского контейнера, но это можно изменить. При наследовании ACE удалить невозможно, но можно добавить.
• При необходимости можно распространить DACL (и SACL) на все вложенные контейнеры и объекты, тем самым заменив их права.
Будем помнить эти несложные правила. Что ж, я, наверное, утомил читателя пространными рассуждениями о принципах строения и работы ACL. Перейдем к более интересной и полезной практической работе. Перед этим, однако, я настаиваю на том, чтобы вы еще раз прочитали раздел Алгоритмы — это основополагающие сведения.
Практика
Как и говорилось, экспериментировать мы будем над ФС и реестром (в систему встроен графический редактор ACL и консольная версия редактора DACL — cacls.exe). В первую очередь, потому, что это актуально для пользователя, а во вторую — что здесь применяются все возможности ACL (включая наследование). В качестве ОС выбрана русская версия Windows XP Professional. Для начала в Windows XP необходимо отключить опцию Использовать простой общий доступ к файлам из закладки Вид окна Свойства папки Панели управления. Данный режим предназначен для неподготовленных пользователей и весьма ограничен в возможностях. В Windows XP Home Edition вам это сделать не удастся, поэтому нужно будет либо работать в Безопасном режиме (Safe Mode), либо воспользоваться консольной утилитой cacls.exe (или ее расширенным аналогом из Support Tools — xcacls.exe).
Итак, сначала откроем редактор ACL. Для файловой системы достаточно в Проводнике в контекстном меню выбрать пункт Свойства, а затем закладку Безопасность (для папок можно сразу выбрать пункт Общий доступ и безопасность...). Для реестра выбираем нужную ветвь (разграничение доступа идет только на ветви, а не отдельные ключи) и в контекстном меню выбираем пункт Разрешения... (для пользователей Windows NT и 2000 придется воспользоваться программой regedt32.exe, так как только она обладает нужной функциональностью). Так как в обоих случаях используется один и тот же редактор ACL и общие принципы, то продолжать я буду на примере свойств папки.
Проделав указанные действия, вы увидите следующее окно (см. рис. 1):
На нем перечислены пользователи и их права. Можно добавлять новых и удалять уже имеющихся (если позволяет наследование). Однако это лишь вершина айсберга — здесь перечислены только общие типы доступа, основанные на нескольких ACE с одинаковым SID. Проверим? Жмем кнопку Дополнительно и оказываемся в настоящем редакторе ACL (см.
рис. 2).
Как видим, тут перечислены все ACE, причем сначала идут запрещающие. Мы можем добавить, удалить и изменить ACE. При добавлении нас спросят об имени пользователя (см. рис. 3), которое можно ввести вручную либо воспользоваться поиском, нажав в появившемся окне Дополнительно, Поиск. Кнопка Типы объектов позволяет указать, что мы ищем: пользователей, группы или встроенных пользователей/группы. Кстати, имя имеет вид Имя контейнера (компьютера в нашем случае)\Имя пользователя, хотя можно просто вводить имя пользователя. С удалением все понятно, а редактирование представляет некоторый интерес.
Если обратить свое внимание на рис. 4, то можно увидеть, что мы вправе менять такие параметры, как имя пользователя (т.е. выбрали редактировать одно, а потом взяли да и сменили), параметры наследования (вложенные папки, объекты и т.д.), ограничение наследования (галочка внизу, становится доступна, когда выбрано наследование для подпапок и файлов) и собственно сами права. Кнопка Очистить выполняет быструю очистку всех галочек в ACE. Если мы поставим сразу запрещающие и разрешающие галочки, то будет создано два ACE: запрещающее и разрешающее (помните о примере). Причем этого можно добиться также и в самом первом окне (до нажатия кнопки Дополнительно) редактированием базовых типов доступа. Думаю, с этим разобрались.
Теперь опять посмотрим на рис. 2. Внизу можно заметить две галочки, отвечающие за наследование. Первая указывает на то, что данный объект наследует права доступа от родительского. Если снять эту галочку, то нам предложат либо скопировать унаследованные права в качестве заданных явно (что в большинстве случаев удобно), либо просто очистить ACL, если нет других ACE, кроме унаследованных. Вторая галочка позволяет заменить разрешения всех объектов и контейнеров заданными здесь, то есть по сути дела заставляет их наследовать права.
Что касается аудита — все абсолютно аналогично рассмотренному DACL включая наследование.
Перейдем к владению (закладка Владелец). По умолчанию владельцем является его создатель, т.е. пользователь либо группа. Однако можно вступить во владение объектом, если вы обладаете таким правом (по умолчанию им обладают члены группы Администраторы) либо если в DACL явно указано, что вы можете изменить владельца. Мы просто выбираем доступного пользователя или группу для владения, если надо, ставим галочку Заменить владельца субконтейнеров и объектов и жмем Применить. Все, объект наш:-).
Ну и напоследок бросим взгляд на закладку Действующие разрешения. Это полезное нововведение XP, позволяющее не просчитывать в уме права конкретного пользователя/группы. Достаточно выбрать имя, и мы получим список прав на основе имеющихся ACE.
Остается добавить, что внешний вид редактора ACL зависит от объекта, разрешения которого мы редактируем, т.е. могут быть недоступны какие-то опции. Если вам интересно, можете поэкспериментировать с консольными утилитами cacls.exe и xcacls.exe. Первая — аналог простого редактора базовых типов доступа, вторая позволяет работать с разрешениями более точно. Не забывайте, что, перетаскивая объект в другую папку в Проводнике, мы тем самым заставляем его унаследовать права этой папки. Чтобы этого не произошло, необходимо пользоваться консольными утилитами с соответствующими ключами либо файл-менеджерами, поддерживающими эту опцию (Total Commander, например).
Заключение
Надеюсь, приведенная мной информация оказалась вам полезной. Если это так, то я и дальше буду продолжать снабжать вас интересными фактами о системах семейства NT. В данной статье использовались материалы из книги Д. Соломона и М. Руссиновича "Внутреннее устройство Microsoft Windows 2000", а в предыдущей (забыл упомянуть) — книга Федора Зубанова "Microsoft Windows 2000. Планирование, развертывание, управление".
Конец.
Creator, creator_vom@tut.by
Рис. 1. Редактор ACL Рис. 2. Расширенный редактор ACL
Рис. 3. Выбор имени Рис. 4. Изменение ACE
Компьютерная газета. Статья была опубликована в номере 29 за 2003 год в рубрике soft :: win
