Как все это работает вместе

Маркер доступа идентифицирует процесс (и его потоки) для ОС, тогда как деск-риптор защиты перечисляет, какие процессы (или группы процессов) имеют доступ к объекту Когда поток открывает описатель объекта, диспетчер объектов и система защиты сопоставляют эту информацию, чтобы определить, следует ли предоставить вызывающему потоку запрашиваемый им описатель.

На рис. 3-12 показано, что происходит, когда пользователь LEES открывает описатель, запрашивая доступ синхронизации к объекту-событию.

Проверяя ACL, система защиты просматривает список, начиная с первого АСЕ. Когда она находит идентификатор защиты вызывающего или его группы, она останавливает поиск и проверяет, разрешает ли данный АСЕ доступ запра-шиваемого типа. Если АСЕ, разрешающий доступ, найден, то поиск прекращается, и вызывающему возвращается описатель. Если система достигает конца списка, не найдя идентификатора защиты вызывающего или его группы, то доступ запрещается.

Рис. 3-12. Проверка прав доступа к объекту.

На рис. 3-12 ACL объекта-события разрешает LEES доступ синхронизации в своем первом элементе. Так как LEES запрашивал именно этот тип доступа, система защиты немедленно прекращает поиск, и диспетчер объектов возвращает LEES описатель, имеющий доступ синхронизации к данному событию. Обратите внимание, что третий АСЕ запрещает LEES доступ синхронизации на основании членства LEES в группе ТЕАМ2. Однако из-за порядка расположения АСЕ в ACL в данном случае третий АСЕ игнорируется. (Это несколько надуманный пример, так как система в общем случае помещает АСЕ, запрещающие доступ, в начало списка.)

Делать такую проверку при всяком использовании описателя процессом было бы неэффективно. ACL может содержать много записей, процесс может за время своей работы осуществлять доступ ко многим объектам, и одновременно могут быть активными несколько процессов. Поэтому проверка осуществляется только при открытии описателя, но не при всяком его использовании. (Обратите внимание, что поскольку код в режиме ядра использует для доступа к объектам указатели, а не описатели, то проверка прав доступа не производится, когда объект используется самой ОС. Другими словами, исполнительная система NT "доверяет" самой себе в смысле защиты.)

Когда LEES воспользуется описателем в следующий раз, диспетчер объектов просто сравнит предоставленный доступ (синхронизацию), хранящиеся в описателе, с типом доступа, который подразумевается вызываемым сервисом. Если вызывается сервис ожидания, то вызов будет успешным. Если же будет выдан запрос на установку события, то сервис потерпит неудачу. Для того, чтобы запросить установку события, LEES следовало запросить при открытии первого описателя доступ как синхронизации, так и изменения состояния; или же теперь нужно открыть новый описатель, запрашивая доступ изменения состояния.

Заметьте, что после того, как процесс успешно открыл описатель, предоставленные ему права доступа не могут быть отозваны системой защиты, даже если изменился ACL объекта. Ему по-прежнему приписывается старый описатель, так как разработчики решили, что эффективные проверки защиты важнее, чем возможность отзыва прав доступа. Последнее потребовало бы полной проверки прав доступа при всяком использовании описателя, а не только при его первоначальном задании, как это делается сейчас. Повышение производительности, достигаемое за счет запоминания предоставленных прав доступа непосредственно в описателе, довольно велико, особенно для объектов с длинным ACL.