Pages Menu
Rss
Categories Menu

Posted | 0 comments

Структура объекта Windows

У каждого объекта Windows есть заголовок и тело объекта. Диспетчер объектов управляет заголовками объектов, а телами объектов управляют компоненты исполняющей системы, являющиеся владельцами тех типов объектов, которые ими созданы. В каждом заголовке объекта содержится также индекс на специальный объект, называемый объектом типа (type object), в котором содержится информация, общая для каждого экземпляра объекта.

Кроме того, существует до пяти дополнительных подзаголовков: информационный заголовок названия, информационный заголовок квоты, информационный заголовок процесса, информационный заголовок дескриптора и информационный заголовок создателя.

структура-объекта

Структура объекта.

Заголовки и тела объектов.

Диспетчер объектов использует данные, хранящиеся в заголовке объекта для управления объектами независимо от их типа. В таблице дано краткое описание полей заголовка объекта, а в следующей таблице дано описание полей, которые могут быть в дополнительных подзаголовках объекта.

Кроме заголовка объекта, содержащего информацию, относящуюся к любым объектам, в подзаголовках содержится дополнительная информация, относящаяся к специфическим аспектам объекта. Учтите, что эти структуры находятся по переменному смещению от заголовка объекта, значение которого зависит от количества подзаголовков, связанных с основным заголовком объекта. (За исключением, как ранее указывалось, информации о создателе.)

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

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

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

поля-заголовка-объекта

Поля заголовка объекта.

Каждый из этих подзаголовков является дополнительным и присутствует только при определенных обстоятельствах, либо в течение запуска системы, либо во время создания объекта. В таблице дается описание этих обстоятельств.

дополнительные-подзаголовки

Дополнительные подзаголовки объекта.

И наконец, ряд атрибутов и (или) флагов определяют поведение объекта во время создания или во время определенных операций. Диспетчер объектов получает эти флаги при каждом создании нового объекта в структуре под названием атрибуты объекта. Эта структура определяет имя объекта, корневой каталог объекта, в который он должен быть вставлен, дескриптор безопасности объекта и флаги атрибутов объекта. В следующей таблице перечислены различные флаги, которые могут быть связаны с объектом.

условия-для-подзаголовков

Условия, требуемые для присутствия подзаголовков объектов.

ПРИМЕЧАНИЕ. Когда объект создается с помощью API-функций в подсистеме Windows (таких как CreateEvent или CreateFile), вызывающая программа не определяет каких-либо атрибутов объекта — DLL-библиотека подсистемы делает все закулисно. Поэтому все именованные объекты, созданные с помощью Win32, помещаются в каталог BaseNamedObjects, либо в его глобальный экземпляр, либо в экземпляр, созданный для конкретного сеанса, поскольку он является корневым каталогом объектов, определяемых Kernelbase.dll в качестве части структуры атрибутов объекта.

Флаги объектов.

Флаг атрибутовФлаг заголовкаНазначение
OBJ_INHERITХранится в записи таблицы дескрипторовОпределяет, будет ли дескриптор объекта унаследован дочерними
процессами, и сможет ли процесс воспользоваться функцией DuplicateHandle для создания копии
OBJ_PERMANENTOB_FLAG_PERMANENT_OBJECTОпределяет способность объекта сохранять поведение, зависящее от рассматриваемых далее подсчетов ссылок
OBJ_EXCLUSIVEOB_FLAG_EXCLUSIVE_OBJECTУказывает на то, что объект может использоваться только тем процессом, который его создал
OBJ_CASE_INSENSITIVEХранится в записи таблицы дескрипторовУказывает на то, что поиск этого объекта в пространстве имен
должен вестись без учета регистра символов. Может быть отменен установкой флага case insensitive в типе объекта
OBJ_OPENIFНе сохраняется, используется во время выполненияУказывает на то, что операция создания объекта с таким же именем должна привести к открытию уже существующего объекта, а не к выдаче ошибки
OBJ_OPENLINKНе сохраняется, используется во время выполненияУказывает на то, что диспетчер объектов должен открыть дескриптор символической ссылки, а не целевого объекта
OBJ_KERNEL_HANDLEOB_FLAG_KERNEL_OBJECTУказывает на то, что дескриптор объекта должен быть дескриптором ядра (подробности будут даны чуть позже)
OBJ_FORCE_ACCESS_CHECKНе сохраняется, используется во время выполненияУказывает на то, что даже при открытии объекта из режима ядра требуется полная проверка прав доступа
OBJ_KERNEL_EXCLUSIVEOB_FLAG_KERNEL_ONLY_ACCESSНе дает процессу пользовательского режима открыть дескриптор объекта; используется для защиты раздела объектов /Device/PhysicalMey
ОтсутствуетOF_FLAG_DEFAULT_
SECURITY_QUOTA
Указывает на то, что дескриптор безопасности объекта использует
исходную квоту в 2 Кбайт
ОтсутствуетOB_FLAG_SINGLE_HANDLE_
ENTRY
Указывает на то, что подзаголовок информации о дескрипторах
содержит только одну запись и не является базой данных
ОтсутствуетOB_FLAG_NEW_OBJECTУказывает на то, что объект был создан, но еще не вставлен в пространство имен объектов
ОтсутствуетOB_FLAG_DELETED_INLINEУказывает на то, что объект удаляется через отложенное удаление рабочего потока

Кроме заголовка у каждого объекта есть его тело, чей формат и содержимое уникальны для типа этого объекта; все объекты одного и того же типа используют один и тот же формат тела. Создавая тип объекта и предоставляя для него соответствующие службы, компонент исполняющей системы может контролировать работу с данными в телах всех объектов данного типа. Поскольку заголовок объекта имеет статический, заранее известный размер, диспетчер объектов может легко найти заголовок объекта путем простого вычитания размера заголовка из указателя на объект. Как уже ранее указывалось, для получения доступа к подзаголовку диспетчер объектов вычитает еще одно известное значение из указателя на заголовок объекта.

Благодаря нормированным структурам заголовка объекта и подзаголовков диспетчер объектов может предоставить небольшой набор служб, способный работать с атрибутами, сохраненными в любом заголовке объекта, и применимый к объектам любого типа (хотя некоторые общие службы не имеют для определенных объектов никакого смысла). Эти общие службы, часть из которых подсистема Windows делает доступной Windows-приложениям, перечислены в следующей таблице.

Хотя эти общие службы объектов поддерживаются для объектов всех типов, у каждого объекта есть свои службы создания (create), открытия (open) и запроса (query). Например, система ввода-вывода реализует службу создания файла для своих файловых объектов, а диспетчер процессов реализует службу создания процесса для своих объектов процесса.

общие-службы-объекта

Общие службы объекта.

Хотя может быть реализована всего одна служба создания объекта, подобная процедура была бы слишком сложной, поскольку набор параметров, необходимых для инициализации, к примеру, файлового объекта, существенно бы отличался от того набора, который понадобился бы для инициализации объекта типа «процесс». Кроме того, диспетчер объектов нес бы дополнительную нагрузку при каждом вызове потоком службы объекта на определение типа объекта, на который ссылается дескриптор, и на вызов соответствующей версии службы.

Post a Reply

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.


↓