Как все это работает вместе
Маркер доступа идентифицирует процесс (и его потоки) для ОС, тогда как дескриптор защиты перечисляет, какие процессы (или группы процессов) имеют доступ к объекту. Когда поток открывает описатель объекта, диспетчер объектов и система защиты сопоставляют эту информацию, чтобы определить, следует ли предоставить вызывающему потоку запрашиваемый им описатель.
На рис. 3-12 показано, что происходит, когда пользователь LEES открывает описатель, запрашивая доступ синхронизации к объекту-событию.
Проверяя ACL, система защиты просматривает список, начиная с первого АСЕ. Когда она находит идентификатор защиты вызывающего или его группы, она останавливает поиск и проверяет, разрешает ли данный АСЕ доступ запрашиваемого типа. Если АСЕ, разрешающий доступ, найден, то поиск прекращается, и вызывающему возвращается описатель. Если система достигает конца списка, не найдя идентификатора защиты вызывающего или его группы, то доступ запрещается.
На рис. 3-12 ACL объекта-события разрешает LEES доступ синхронизации в своем первом элементе. Так как LEES запрашивал именно этот тип доступа, система защиты немедленно прекращает поиск, и диспетчер объектов возвращает LEES описатель, имеющий доступ синхронизации к данному событию. Обратите внимание, что третий АСЕ запрещает LEES доступ синхронизации на основании членства LEES в группе ТЕАМ2. Однако из-за порядка расположения АСЕ в ACL в данном случае третий АСЕ игнорируется. (Это несколько надуманный пример, так как система в общем случае помещает АСЕ, запрещающие доступ, в начало списка.)
Рис. 3-12. Проверка прав доступа к объекту.
Делать такую проверку при всяком использовании описателя процессом было бы неэффективно. ACL может содержать много записей, процесс может за время своей работы осуществлять доступ ко многим объектам, и одновременно могут быть активными несколько процессов. Поэтому проверка осуществляется только при открытии описателя, но не при всяком его использовании. (Обратите внимание, что поскольку код в режиме ядра использует для доступа к объектам указатели, а не описатели, то проверка прав доступа не производится, когда объект используется самой ОС. Другими словами, исполнительная система NT "доверяет" самой себе в смысле защиты.)
Когда LEES воспользуется описателем в следующий раз, диспетчер объектов просто сравнит предоставленный доступ (синхронизацию), хранящиеся в описателе, с типом доступа, который подразумевается вызываемым сервисом. Если вызывается сервис ожидания, то вызов будет успешным. Если же будет выдан запрос на установку события, то сервис потерпит неудачу. Для того, чтобы запросить установку события, LEES следовало запросить при открытии первого описателя доступ как синхронизации, так и изменения состояния; или же теперь нужно открыть новый описатель, запрашивая доступ изменения состояния.
Заметьте, что после того, как процесс успешно открыл описатель, предоставленные ему права доступа не могут быть отозваны системой защиты, даже если изменился ACL объекта. Ему по-прежнему приписывается старый описатель, так как разработчики решили, что эффективные проверки защиты важнее, чем возможность отзыва прав доступа. Последнее потребовало бы полной проверки прав доступа при всяком использовании описателя, а не только при его первоначальном задании, как это делается сейчас. Повышение производительности, достигаемое за счет запоминания предоставленных прав доступа непосредственно в описателе, довольно велико, особенно для объектов с длинным ACL.
Процессы
и потоки:
Процессы: общие сведения, адресное пространство.
Набор ресурсов, объект-процесс.
Поток. Многозадачность и мультипроцессорная обработка.
Многопоточность.
Объект-поток.
Синхронизация процессов
и потоков:
Синхронизация процессов и потоков.
Оповещения и асинхронные вызовы процедур.
Структура процессов. Требования подсистем среды.
Базовая структура процессов. Управление клиентскими процессами. Предотвращение неправильного использования.
Защищенные подсистемы:
Windows NT и защищенные подсистемы. Общие сведения.
Модель клиент-сервер. Поддержка нескольких сред.
Защита памяти.
Производительность.
Взаимодействие с подсистемами. Регистрация пользователя.
Выполнение приложений.
Сетевое Математическое Обеспечение (СМО)
вопросы к экзамену
Подсистема Win32:
Подсистема Win32. 32-х разрядный API.
Структура.
Конструктивные изменения.
API: MS-DOS и 16-ти разрядной Windows. Виртуальные DOS-машины.
ОС Windows на Win32.
Передача сообщений LPC:
Передача сообщений при помощи механизма LPC. Объект-порт.
Способы передачи: копирование в порт, через совместно используемую память.
Обратные вызовы. Быстрый LPC.
Виртуальная память:
Диспетчер. Виртуальная память.
Средства пользовательского режима:
управление памятью, совместное использование.
Совместное использование: секции, проекции и проецируемые файлы.
Объект-секция. Способы защиты памяти.
Собственная память процесса. Совместное использование памяти.
Реализация виртуальной памяти:
Адресное пространство. Подкачка страниц.
Механизмы подкачки страниц.
Стратегия подкачки и рабочие наборы.
Базы данных страничных фреймов.
Дескрипторы виртуальных адресов.
Мультипроцессорная обработка и переносимость.
Ядро:
Ядро: общие сведения. Планирование потоков.
Объекты: процесс ядра и поток ядра.
Приоритеты планирования. Переключение контекста.
Обработка прерываний и исключений. Обработчик ловушки.
Распределение прерываний. Типы и приоритеты прерываний.
Обработка прерываний
и исключений:
Таблица распределения прерываний. Программные прерывания.
Прерывания асинхронного вызова процедур (APC).
Распределение: исключений, вызовов системных сервисов.
Синхронизация: многопроцессорная, на уровне ядра.
Синхронизация на уровне исполнительной системы.
Восстановление после сбоя питания.
Сеть:
Сеть в Windows NT. История. Опорная модель OSI.
Сетевые API. Разрешение имен.
Встроенные сетевые компоненты: редиректор, сервер.
Открытая архитектура. Доступ пользовательского режима:
маршрутизатор для API Wnet, многосетевой UNC для файлового I\O Win32.
Транспортные протоколы. Среда NDIS для сетевых драйверов.
Среда распределенных вычислений. RPC. Именованные каналы.
Корпоративные сети и распределенная защита.