Работа по дисциплине СПО “Диспетчер объектов и контроль доступа”

Министерство обоазования Российской федерации

Новосибирский Государственный Технический Университет

Работа по дисциплине СПО

“Диспетчер объектов и контроль доступа”

Хелен Кастер “Основы Widows NT и NTFS”

Студенты:

Преподаватель:

Новосибирск

2002

Оглавление

ДИСПЕТЧЕР ОБЪЕКТОВ И КОНТРОЛЬ ДОСТУПА 3

1. Объекты исполнительной системы NT 3

1.1 Использование объектов 5

1.1.1 Файловая модель 7

1.1.2 Объектная модель 7

1.2 Структура объектов 9

1.3 Типы объектов 12

2. Управление объектами 13

2.1 Имена объектов 13

2.1.1 Каталоги 14

2.1.2 Домены 16

2.1.3 Символические связи 18

2.2 Описатели объектов 20

2.2.1 Удержание объектов 21

2.2.2 Учет использования ресурсов 22

2.3 Методы объектов 23

3. Защита объектов 25

3.1 Маркеры доступа 26

3.2 Списки контроля доступа 28

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

4. Заключение 31

5. Литература 31

ДИСПЕТЧЕР ОБЪЕКТОВ И КОНТРОЛЬ ДОСТУПА

Объектно-ориентированные языки, пользовательские интерфейсы и ОС были популярной темой среди компьютерных энтузиастов во второй половине 80-х годов. Объекты вдруг стали рекламироваться в качестве панацеи от всех проблем в программировании. Однако объекты — это не есть что-то новое. Впервые они появились в конце 60-х в языках программирования, таких как Симула, которые разрабатывались в основном для создания программ моделирования. Подобные программы моделируют поведение объектов реального мира. Таким образом, объектно-ориентированное программирование, которое обеспечивает способ представления и манипулирования как физическими, так и абстрактными объектами, является естественным подходом в данной области.

Операционные системы также работают с объектами. Их объектами являются аппаратные ресурсы, например устройства ввода-вывода или память, либо программные ресурсы, такие как файлы, процессы и семафоры Большинство ОС ставят во главу угла различия между ресурсами и работают с каждым типом ресурсов по-своему В то же время представление ресурсов в виде объектов использует сходство между ними. При этом все управление ресурсами сосредотачивается в одном месте, и обеспечивается общая модель их использования

Наше путешествие внутри Windows NT начинается с исполнительной системы NT, а конкретно, с ее объектов. Трудно начать откуда-либо еще, так как процессы, потоки, файлы и даже подсистема Win32 (процесс) — все это объекты. Следовательно, изучение системы объектов NT поможет нам в понимании других, самых разных частей ОС.

В первом разделе этой главы описываются существующие в Windows NT типы объектов и способы их использования Предмет второго раздела — структура объектов и то, как диспетчер объектов управляет ими. Третий раздел посвящен главной задаче системы защиты Windows NT. защите объектов.

1. Объекты исполнительной системы NT

Что такое объект? В исполнительной системе NT объект — это отдельный образец статически определенного типа объектов. Существующий во время выполнения Тип объектов (object type), иногда называемый классом объектов (object class), включает определенный системой тип данных, сервисы, работающие с образцами этого типа, и набор атрибутов объекта. При написании Win52-приложения Вы столкнетесь с объектами, представляющими, к примеру, процесс, поток, файл, событие. В основе этих объектов лежат низкоуровневые объекты, которые создаются и управляются исполнительной системой NT. В Windows NT процесс — это пример объекта типа "процесс", файл — пример объекта типа "файл" и т. д.

Атрибут объекта (object attribute) — это поле данных внутри объекта, частично определяющее его состояние[1]. Объект типа "стек", например, имел бы в качестве одного из самых важных атрибутов указатель стека. Объектные сер­висы (object services) — способы манипулирования объектами — обычно считы­вают или изменяют атрибуты объекта. Например, сервис "push" (поместить в стек) для объекта-стека изменял бы значение указа-геля стека.

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

эта техника позволяет в дальнейшем легко изменять реализацию объекта.

Команда проектировщиков исполнительной системы NT приняла реше­ние использовать объекты для представления системных ресурсов, потому что объекты дают способ централизованного выполнения трех важных (и часто ру­тинных) задач ОС:

·  Присвоение системным ресурсам читабельных имен

·  Совместное использование ресурсов и данных разными процессами

·  Защита ресурсов от несанкционированного доступа.

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

Несмотря на то, что объекты широко используются для представления совместно используемых системных ресурсов, Windows NT не является объект­но-ориентированной системой в строгом смысле слова. Большая часть кода ОС написана на С, чтобы обеспечить переносимость и из-за того, что сред­ства разработки широко доступны. С не поддерживает непосредственно объектно-ориентированные конструкции, такие как динамическое опреде­ление типа данных, полиморфные функции или наследование классов. Таким образом, реализация объектов в Windows NT, выполненная на С, заимствует идеи, но не зависит от средств, предоставляемых конкретными объектно-ориентированными языками.

Диспетчер объектов (object manager) — это компонент исполнительной системы NT, отвечающий за создание, удаление, защиту и учет объектов NT. Диспетчер объектов централизует операции управления ресурсами, которые иначе были бы разбросаны по всей ОС. Лу Пераццоли (Lou Perazzoli), технический управляющий и руководитель проекта разработки Windows NT, и Стив Вуд (Steve Wood), программист ОС Microsoft с 9-летним стажем, спроектировали диспетчер объектов и определили следующие цели его реализации:

·  Обеспечить общий, унифицированный механизм использования системных ресурсов.

·  Сосредоточить защиту объектов в одном месте ОС, чтобы удовлетворить требованиям правительства США по защите класса С2.

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

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

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

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

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

1.1 Использование объектов

Исполнительная система NT реализует два типа объектов: объекты исполнительной системы, (executive object) и объекты, ядра (kernel object). Объекты исполнительной системы представляются различными компонентами исполнительной системы NT. Они доступны программам пользовательского режима (защищенным подсистемам) посредством базовых сервисов NT и могут создаваться и использоваться как подсистемами, так и исполнительной системой NT.

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

Таблица 1. Объекты исполнительной системы

Тип объекта	Реализующий компонент	Что представляет собой
Процесс	Диспетчер процессов	Один вызов программы, включая адресное пространство и ресурсы, необходимые для ее исполнения
Поток	Диспетчер процессов	Исполняемая сущность внутри процесса
Секция	Диспетчер памяти	Область совместно используемой памяти
Файл	Диспетчер ввода-вывода	Образец открытого файла или устройства ввода-вывода
Порт	Механизм LPC	Место назначения сообщений, пересылаемых между процессами.
Маркер доступа	Система защиты	Закодированный идентификатор, содержа­ щий информацию о правах доступа зарегистрировавшегося в системе пользователя
Событие	Вспомогательные сервисы исполнительной системы	Объявление о том, что произошло системное событие
Пара событий	Тоже	Уведомление о том, что специальный по­ток клиента скопировал сообщение серве­ру Win32 или наоборот (используется только подсистемой Win32)
Мутант[2]	То же	Механизм обеспечения взаимного исклю­чения для сред Win32 и OS/2
Семафор	Тоже	Счетчик, регулирующий число потоков, которые могут использовать некоторый ресурс
Таймер[3]	Тоже	Счетчик времени
Каталог объектов	Диспетчер объектов	Хранилище в памяти для имен объектов
Символическая связь	Тоже	Механизм косвенной ссылки на имя объекта
Профиль	Ядро	Механизм, позволяющий оценить распреде­ление времени исполнения внутри блока кода (для оптимизации производительности)
Параметр Реестра	Диспетчер Конфигурации	Индексный ключ для ссылки на записи в базе данных конфигурации Windows NT

Каждая подсистема Windows NT создает для своих приложений разные образы ОС. Объекты исполнительной системы и объектные сервисы — это примитивы, используемые подсистемами среды для создания их собственных версий объектов и других ресурсов Набор объектов, которые подсистема среды предоставляет своим приложениям, может быть шире или уже предоставляемого исполнительной системой NT Некоторые подсистемы, такие как POSIX, вообще не поддерживают объекты как объекты Подсистема POSIX использует объекты и сервисы исполнительной системы как основу, чтобы представить своим приложениям процессы, каналы и другие ресурсы своим собственным способом Другие подсистемы, например Win32, используют объекты исполнительной системы NT для создания собственных версий объектов Подсистема Win32 предоставляет своим приложениям мьютексы и семафоры — и те и другие непосредственно основаны на объектах исполнительной системы NT Кроме того, подсистема Win32 реализует именованные каналы и почтовые ящики — ресурсы, в основе которых лежат файловые объекты исполнительной системы NT.

Данная глава посвящена объектам исполнительной системы, тем, которые реализуются исполнительной системой NT. Их не следует путать с объектами, доступ к которым предоставляется прикладным программам посредством API Win32, POSIX или OS/2.

1.1.1 Файловая модель

Для прикладного программиста Windows NT выглядит или как Windows, или как MS-DOS, или как POSIX, или как OS/2. Только системным программистам, которые пишут подсистему среды, файловую систему, базовый драйвер устройства или другую специализированную программу, приходится изучать объекты исполнительной системы и непосредственно их использовать

Обычно объекты исполнительной системы создаются либо защищенной подсистемой, в качестве непосредственной реакции на некоторое действие пользователя, либо различными компонентами ОС в процессе их нормальной работы. Например, для того чтобы создать файл, приложение Win32 вызывает функцию API Win32 CreateFile(). В свою очередь, подсистема Win32 вызывает базовый сервис NT, создающий файловый объект исполнительной системы Когда затем приложение читает файл или пишет в него, подсистема Win32 и исполнительная система NT используют файловый объект для обращения к файлу

Работа с файлами — это нетипичный случай для объектной системы NT, так как файлы являются постоянными ресурсами и расположены не в памяти. Однако они важны, так как модель работы с файлами, используемая большинством языков программирования, удобна для создания и использования объектов NT Ниже приведены интересующие нас характеристики файловой модели:

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

·  При открытии файла задается тип операций, которые с ним будут про­изводиться: например, чтение, запись или дописывание к концу файла.

·  Файловая система открывает файл и возвращает его описатель, кото­рый используется в последующих операциях для ссылки на этот файл. Когда работа с файлом закончена, Вы закрываете описатель файла.

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

С некоторыми отклонениями, объектная модель Windows NT имитирует файловую модель. Основные отличия состоят в том, что описатели называются описателями объектов (object handles) и объекты хранятся в памяти, а не на физическом устройстве. В следующем разделе объектная модель NT рассматри­вается более подробно.

1.1.2 Объектная модель

Как и в большинстве ОС, единицей работы в NT является процесс. Каждому про­цессу выделяется набор ресурсов, позволяющих ему выполнять свою работу: по­ток, чтобы можно было выполнять программы, и адресное пространство для хра­нения кода и данных. В процессе работы поток может запросить для своего про­цесса дополнительные ресурсы путем создания объектов или открытия описате­лей существующих объектов. Описатели объекта уникальны для процесса и ука­зывают на доступ процесса к системным ресурсам. Они могут быть использованы для вызова базовых сервисов объекта, осуществляющих действия с ресурсами.

Подсистема Win32 — это процесс NT, который выступает как сервер для приложений Win32. Когда приложение вызывает функцию API Win32, которая прямо или косвенно создает объект, подсистема Win32 обращается к некоему объектному сервису NT. Здесь в дело вступает диспетчер объектов NT, который выполняет следующие функции:

·  Выделяет память для объекта.

·  Присоединяет к объекту дескриптор защиты (security descriptor), кото­рый определяет, кому и как разрешено использовать объект.

·  Создает и поддерживает структуру каталога объектов, где хранятся име­на объектов.

·  Создает описатель объекта и возвращает его вызывающей программе.

Все процессы пользовательского режима, включая подсистемы среды, должны получить описатель объекта, прежде чем их потоки смогут использо­вать этот объект. Идея применения описателей для манипулирования систем­ными ресурсами отнюдь не нова. Библиотеки периода выполнения С и Пас­каля (а также других языков), например, возвращают описатели при откры­тии файлов. Аналогично, приложения Win32 используют различные типы| описателей для управления окнами, курсором мыши и значками. В обоих случаях описатели служат косвенными указателями на системные ресурсы; эта косвенность предотвращает непосредственный доступ приложений к сис­темным структурам данных.

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

·  Он защищает объекты. Всякий раз, когда поток использует описатель, диспетчер объекта проверяет наличие у потока прав использовать объект так, как он это пытается сделать.

·  Он контролирует, кто использует объект, и поэтому может удалить временные объекты, которые более не нужны. Диспетчер объектов не удалит объект, пока у какого-либо процесса имеется описатель этого объекта (или пока у системы есть указатель на него).

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

Первая задача, защита объектов, и составляет суть системы защиты Windows NT. Ее реализация многое заимствует из файловой модели и до некоторой степени видима программам, использующим API Win32. Ниже дается краткое введение в тему защиты объектов исполнительной системы NT, к которой мы еще обратимся далее в этой главе.

Вернемся к аналогии с файлами: при открытии файла необходимо указать, собираетесь ли Вы использовать его для чтения или для записи. Если Вы попытаетесь записать в файл, который открыт только для чтения, то получите ошибку. Аналогично, в исполнительной системе NT, когда процесс создает объект или открывает описатель существующего объекта, он должен задать набор запрашиваемых прав доступа (desired access rights) — т. е. указать, что он намерен делать с объектом. Можно запросить либо набор стандартных прав доступа (таких как чтение, запись или исполнение), применимых к объектам всех типов, либо спе­цифических прав доступа, состав которых зависит от типа объекта. Например, процесс может запросить доступ для удаления файлового объекта или дописывания к его концу. Аналогично, он может запросить возможность приостанавли­вать или завершать объект-поток.

Когда процесс открывает описатель объекта, диспетчер объектов вызыва­ет справочный монитор защиты (security reference monitor) — часть системы защиты, работающую в режиме ядра — и посылает ей набор запрашиваемых процессом прав доступа. Справочный монитор защиты проверяет, разрешает ли дескриптор защиты объекта (security descriptor) доступ, запрашиваемый процессом[4]. Если да, то справочный монитор защиты возвращает набор прав

доступа, предоставленных процессу (granted access rights), и диспетчер объек­тов сохраняет их в создаваемом описателе объекта[5].

После этого всякий раз, когда потоки процесса используют описатель, дис­петчер объектов быстро проверяет, соответствует ли хранящийся в описателе набор предоставленных прав доступа типу использования, который подразумева­ется объектным сервисом, вызванным потоком. Например, если процесс запраши­вал доступ по чтению к объекту-секции, а затем вызвал сервис для записи в эту секцию, то данный вызов завершится с ошибкой. Способ, которым система защи­ты определяет, кто к каким объектам имеет доступ, рассматривается в разд. 3.

1.2 Структура объектов

Каждый объект NT относится к некоторому типу объектов. Тип объекта опре­деляет, какие данные содержит объект, а также базовые системные сервисы, которые могут к нему применяться. Для универсальности обработки разных объектов диспетчеру объектов необходимо, чтобы каждый объект содержал в заданном месте несколько полей со стандартной информацией. При наличии этих данных диспетчеру объектов не требуется знать, что еще содержится в объекте. Для отделения стандартных данных объекта от специфичных каждый объект разделен на две части — заголовок и тело. Диспетчер объектов работает с заголовком, а другие компоненты исполнительной системы — с телами объек­тов создаваемых ими типов,

Диспетчер объектов использует данные заголовка объекта для обработки объектов способом, не зависящим от их Типа. На рис.1 показаны данные, или атрибуты, содержащиеся в заголовке объекта. Табл.2 кратко описывает эти атрибуты.

рис.1. Содержимое заголовка объекта.

Таблица 2. Стандартные атрибуты заголовка объекта

Атрибут	Назначение
Имя объекта	Делает объект видимым другим процессам для совместного использования.
Каталог объектов	Обеспечивает иерархическую структуру, в которой хранятся имена объектов.
Дескриптор защиты	Определяет, кто и каким образом может использовать данный объект
Расход квоты	Задает квоту на использование ресурсов, которая списывается с процесса, когда тот открывает описатель данного объекта
Счетчик открытых описателей	Подсчитывает количество открытых описателей данного объекта
База данных открытых описателей	Содержит список процессов, открывших описатели данного объекта
Временный/постоянный статус	Указывает, можно ли уничтожить имя и освободить память объекта, если он более не используется
Режим: пользовательский/ядра	Определяет доступность объекта в пользовательском режиме
Указатель на типовой объект	Ссылается на типовой объект, который содержит атрибуты, общие для набора однотипных объектов

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

Таблица 3. Универсальные объектные сервисы

Сервис	Назначение
Закрыть	Закрывает описатель объекта
Дублировать	Обеспечивает совместное использование объекта путем дуб­лирования его описателя и передачи копии другому процессу
Опросить объект	Получает информацию о стандартных атрибутах объекта
Опросить защиту	Получает дескриптор защиты объекта
Установить защиту	Изменяет параметры защиты объекта
Ждать одного объекта	Синхронизирует исполнение потока с одним объектом
Ждать несколько объектов	Синхронизирует исполнение потока с несколькими объектами

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

Любой компонент исполнительной системы может задавать тип объек­тов, и большинство из них делают это. Задание типа объекта состоит в том, чтобы определить данные, которые будут храниться в теле каждого объекта

этого типа, сообщить размер тела диспетчеру объектов, чтобы он мог выде­лить нужный объем памяти при создании объекта, и предоставить сервисы для нового типа объектов. Например, диспетчер процессов определяет тело объек­тов—процессов и обеспечивает сервисы для работы с хранящимися в нем дан­ными. Аналогично, диспетчер объектов определяет формат тела и сервисы для файлового объекта. Содержимое тел различных объектов, а также определяю­щих их компонентов исполнительной системы NT описывается ниже.

1.3 Типы объектов

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

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

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

 

Рис.2. объекты-процессы и типовой объект-процесс.

Однако некоторые определяемые ими атрибуты видимы посредством базовых сервисов и функций API Win32. Атрибуты, хранящиеся в телах типовых объектов, приведены в табл. 4.

Таблица 4. Атрибуты типового объекта

Атрибут	Назначение
Имя типа объекта	Название объектов данного типа ("процесс", событие", порт" и т. д.)
Типы доступа	Типы доступа, которые могут быть запрошены потоком при открытии описателя объекта данного типа ("чтение", "запись", "завершить", "приостановить" и т. д.)
Возможности синхронизации	Может ли поток ожидать у объектов данного типа
Резидентный/нере­зидентный	Могут ли объекты данного типа выгружаться из памяти
Методы	Одна или несколько процедур, вызываемых диспетчером объекта автоматически в некоторых точках времени жиз­ни объекта

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

Последний атрибут в списке — методы — состоит из набора внутренних процедур, аналогичных конструкторам и деструкторам C++, т. е. процедурам, которые автоматически вызываются при создании и разрушении объекта. Дис­петчер объектов развивает эту идею, вызывая методы объектов и в других ситу­ациях, таких как открытие и закрытие описателя объекта или попытка измене­ния параметров защиты объекта. Некоторые типы объектов определяют методы, а некоторые нет, в зависимости от назначения типа.

Итак, объекты исполнительной системы NT состоят из двух частей: заголов­ка объекта, управляемого диспетчером объектов, и тела объекта, которое управля­ется компонентом ОС, создавшим данный тип. Одним из атрибутов заголовка объекта является указатель на типовой объект-структуру, определяющий стати­ческие атрибуты объектов данного типа. Новый тип объектов может быть опреде­лен любым компонентом исполнительной системы NT, и каждый компонент пре­доставляет сервисы для определенных им типов объектов.

2. Управление объектами

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

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

2.1 Имена объектов

При создании большого количества объектов необходимо иметь эффективную систему их отслеживания. Для этой цели диспетчеру объектов необходимы:

·  способ отличить один объект от другого;

·  метод поиска и выборки заданного объекта.

Первое требование выполняется благодаря тому, что объектам можно на­значать имена. Тем самым системы расширены по сравнению с тем, что обычно предоставляется большинством ОС — способностью именовать некоторые ре­сурсы, файлы, каналы или блоки совместно используемой памяти. В отличие от других ОС, исполнительная система NT позволяет назначать имя любому ресур­су, который представлен объектом.

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

Имена объектов позволяют выполнить и еще одно требование — дают процессам возможность совместно использовать объекты. Пространство имен объектов исполнительной системы NT является глобальным, доступным всем процессам в системе. Один процесс может создать объект и поместить его имя в глобальное пространство имен, а другой процесс может открыть описатель данного объекта, указав его имя. Если объект не предназначен для совместного использования подобным образом, то его создателю не нужно присваивать объекту имя.

Для повышения эффективности диспетчер объектов не ищет имя объекта всякий раз, когда кто-нибудь использует объект. Поиск по имени осуществляет­ся лишь в двух случаях. Во-первых, когда процесс создает новый объект, диспет­чер объектов, прежде чем поместить имя в глобальное пространство имен, осу­ществляет поиск по нему, чтобы убедиться, что оно уже не присвоено другому объекту. Во-вторых, когда процесс открывает описатель именованного объекта, диспетчер объектов осуществляет поиск по имени, находит объект и возвраща­ет его описатель; после этого для ссылок на объект вызывающий процесс ис­пользует возвращенный описатель. При поиске имени диспетчер объектов по­зволяет указать, игнорировать или различать регистр букв, что обеспечивает поддержку POSIX и других сред, где учитывается регистр букв в именах файлов.

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

2.1.1 Каталоги

При определении структуры имен объектов основным ограничением для раз­работчиков были файловые системы MS-DOS и POSIX, в которых существуют иерархические схемы имен файлов и каталогов. В исполнительной системе NT файлы и каталоги файлов представлены как объекты; таким образом, чтобы выполнять поиск файловых объектов, диспетчер объектов обязан понимать формат имен файлов. Следовательно, имеет смысл, чтобы имена объектов напо­минали имена файлов.

Имена объектов NT имеют некоторые характеристики имен файлов как MS-DOS, так и POSIX. На рис.3 изображена иерархия имен объектов NT в виде дерева.

Обратите внимание, что корнем иерархического дерева является обратная косая черта (\) как в MS-DOS. Листовые узлы представляют отдельные объекты, а промежуточные узлы — имена каталогов объектов. Для получения имени объекта следует начать из корня и пройти до данного объекта по всей иерархии. Как в MS-DOS и OS/2, для разделения имен при указании пути используется об­ратная косая черта.

Объект-каталог объектов (object directory object) — это средство под­держания изображенной выше иерархической структуры имен диспетчером

 

рис.3.Иерархия имен объектов.

объектов. Он является аналогом каталога файловой системы и содержит имена других объектов, возможно, даже других каталогов объектов. Подсистема Win32 и другие подсистемы, равно как и компоненты исполнительной систе­мы NT, могут создавать произвольные иерархии каталогов объектов для хране­ния именованных объектов.

На рис.4 показана обобщенная сводка важнейших, уникальных характе­ристик объекта—каталога объектов. На этом и других рисунках в данной книге тип объекта (object type) обозначает описываемый класс объектов. Атрибуты тела объекта (object body attributes) обозначают поля данных, хранящиеся в телах объектов этого типа. Сервисы (services) — это базовые системные сервисы, предоставляемые некоторым компонентом исполнительной системы NT для ра­боты с атрибутами объекта. (Атрибуты из заголовка объекта не показаны, так как они одинаковы для объектов всех типов. Аналогично, универсальные объект­ные сервисы, описанные выше, работают с объектами всех типов.)

Рис.4 Объект-каталог объектов[6]

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

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

Каталоги объектов могут создаваться как кодом ядра, так и кодом пользо­вательского режима (таким как подсистемы). Например, диспетчер ввода-выво­да создает каталог с именем \Device, в котором хранятся имена объектов, пред­ставляющих устройства ввода-вывода.

Трио объектных сервисов создания, открытия и опроса часто встречается в исполнительной системе NT. Система ввода-вывода реализует сервис откры­тия файла для своих файловых объектов, а диспетчер объектов — сервис созда­ния процесса для своих объектов-процессов. Хотя разработчики NT рассматривали возможность использования единого, виртуального сервиса создания объекта, такая процедура на С была бы очень сложной, так как набор парамет­ров, необходимый для инициализации, к примеру, файлового объекта, заметно отличается от того, который нужен для инициализации объекта-процесса Еди­ная процедура на С становилась бы все более сложной по мере добавления к системе новых типов объектов Кроме того, при всяком вызове потоком объект­ного сервиса диспетчеру объектов пришлось бы нести дополнительные наклад­ные расходы на определение типа объекта, на который ссылается описатель, и вызов соответствующей версии сервиса. По этим и другим причинам сервисы создания, открытия и опроса реализованы отдельно для каждого типа объектов.

2.1.2 Домены

Пространство имен объектов образует как бы зонтик, под которым можно раз­местить автономные наборы объектов, называемые доменами объектов (object domains), тем самым расширяя пространство объектов. Диспетчер ввода-выво­да, например, — это вторичный диспетчер объектов, управляющий доменом объектов, который состоит из дисковых файлов, каталогов и устройств. Дис­петчер объектов дает системе ввода-вывода возможность упрятать объекты файловой системы в листовом узле пространства имен. Предположим, напри­мер, что структура каталогов на гибком диске такова:

 

В пространстве имен объектов эта структура каталогов выглядит как на рис.5. Каждое имя в изображенном дереве представляет объект исполни­тельной системы NT. Пространство имен файловой системы присоединено к пространству имен объектов под именем \Device\Floppy0.

Когда пользователь Microsoft Excel for Windows пытается открыть файл A:\budget\accounts. xls, диспетчер объектов открывает описатель файлового объекта с именем \Device\Floppy0\budget\accounts. xls[7]. Для этой цели диспетчер объектов просматривает свое пространство имен до тех пор, пока не дойдет до объекта FloppyO, являющегося специальным объектом-устройсгвом, с которым связан метод разбора. Тогда диспетчер объектов приостанавливает поиск имени и вызывает метод разбора, передавая ему имя \budget\accounts. xls. Метод разбо­ра реализуется системой ввода-вывода, которая обращается к соответствующей файловой системе для поиска и открытия файла на гибком диске. Дальнейшее описание методов см. в разд. 2.3.

 

Пространство имен

диспетчера объектов

 

Пространство имен

системы

рис.5. Структура объектов.

2.1.3 Символические связи

В некоторых файловых системах (например, в некоторых системах UNIX) сим­волическая связь дает пользователю возможность создать имя файла или катало­га, которое при его использовании транслируется ОС в другое имя файла или каталога. Это простой метод неявного совместного использования файлов или содержимого каталога — путем создания перекрестной ссылки между разными каталогами в обычно иерархической структуре каталогов.

Диспетчер объектов NT реализует объект, называемый объект-символи­ческая связь (symbolic link object), который выполняет аналогичные функции для имен объектов в его пространстве объектов. При ссылке на имя объекта-символической связи диспетчер объектов проходит по своему пространству имен до тех пор, пока не дойдет до этого объекта. Далее он просматривает со­держимое символической связи и находит строку, которую подставляет вместо имени этой связи. Затем вновь производится поиск имени. Символическая связь

рис.6. Объект-символическая связь.

может встретиться в любом месте строки-имени объекта. На рис.6 показаны атрибуты и сервисы для типа объектов "символическая связь".

Один из примеров использования символических связей исполнительной системой NT — это трансляция имен устройств MS-DOS в имена объектов Windows NT. В MS-DOS гибкие и жесткие диски обозначаются как А:, В:, С: и т. д. Более того, пользователь может добавить новые имена устройств или псевдоус­тройств, например, создав дополнительные разделы на жестком диске или на­значив имя устройства сетевому каталогу на удаленной машине. После их созда­ния эти имена должны быть видимы всем процессам в системе.

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

При создании пользователем или приложением нового обозначения дис­ка подсистема Win32 добавляет еще один объект в каталог объектов \DosDevices. Однако объекты, представляющие настоящие физические устрой­ства, располагаются в других местах дерева, как изображено на рисунке:

Объекты с именами А:, В:, С: и т. д. — это символические связи. Каждая из них содержит имя объекта-физического устройства, к которому отно­сится буква Таким образом, если пользователь Excel for Windows открывает электронную таблицу, хранящуюся в A:\budget\accounts. xls, то подсистема Win32 преобразует это имя и открывает описатель файлового объекта с именем \DosDevices\A:\budget\accounts. xls. Для поиска файлового объекта диспетчер объектов проходит по дереву имен объектов, пока не найдет объект под именем А: и не обнаружит, что он является символической свя­зью Он проверяет содержимое символической связи и находит в ней строку \Device\FloppyO, как показано ниже:

Диспетчер объектов берет строку, найденную внутри символической ссылки, и добавляет к ее концу остаток оригинальной строки (\Device\FloppvO плюс \budget\accounts. xls). После этого он вновь начинает поиск файлового объекта с корня дерева.

Символические ссылки позволяют подсистемам (или другим программам) создавать для объектов исполнительной системы псевдонимы, которые подси­стемы при необходимости могут изменять. Более того, подсистема может по­лучить выигрыш в производительности, сохраняя глобальные данные, такие как имена устройств, непосредственно в исполнительной системе NT, а не в собственном адресном пространстве. Дальнейшее обсуждение вопроса произ­водительности подсистем см. в гл. 5, "Windows и защищенные подсистемы".

2.2 Описатели объектов

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

Описатель объекта NT — это индекс в специфичной для процесса таблице объектов (object table). Таблица объектов процесса содержит указатели на все объекты, описатели которых открыты процессом. Процесс может получить описатель объекта, создав объект, или открыв описатель существующего объек­та, или унаследовав описатель от другого процесса, или получив дубликат опи­сателя из другого процесса. На рис. 3-7 показана связь между процессом и его таблицей объектов.

Каждый вход таблицы объектов содержит предоставленные права доступа для соответствующего описателя и сто режим наследования (inheritance designa­tion) — иными словами, получат ли процессы, созданные данным процессом копию этого описателя в своих таблицах объектов. Хотя термин описатель (handle), строго говоря, относится только к индексу в таблице, разработчики используют этот термин и для обозначения данных, хранящихся в соответству­ющем входе таблицы.

рис.7. Структура таблицы объектов.

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

Создатель объекта определяет, могут ли описатели объекта наследо­ваться из процесса теми процессами, которые он создал. Это средство по­зволяет поддерживать среды, включая Win32 и POSIX, разрешающие насле­дование ресурсов.

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

рис.8. Совместное использование объекта.

объект-процесс, диспетчер объектов вызывает метод "удалить" для объектов-процессов, который закрывает все описатели в таблице объектов процесса.

2.2.1 Удержание объектов

Так как все процессы пользовательского режима, осуществляющие доступ к некоторому объекту, должны вначале открыть его описатель, то диспетчер объек­тов может легко отслеживать, сколько процессов, и даже какие именно, исполь­зуют данный объект. Отслеживание открытых описателей — это первый шаг в реализации удержания объектов (object retention), т. е. сохранения временных объектов только на то время, пока они используются, с последующим удалением,

Удержание объектов включает две фазы. Первая фаза называется удержа­нием имени (name retention) и управляется количеством открытых описателей данного объекта. Всякий раз, когда процесс открывает описатель объекта, дис­петчер объектов увеличивает счетчик открытых описателей в заголовке объекта (см. рис. 1.) После того, как процесс закончил работу с объектом и закрыл имеющиеся у него описатели данного объекта, диспетчер объектов уменьшает счетчик. Когда счетчик обнуляется, диспетчер объектов удаляет объект из своего пространства имен. В результате новые процессы не могут открыть описатели данного объекта. (Имена постоянных объектов не удаляются, поскольку эти объекты представляют такие сущности, как физические устройства, которые остаются на месте, даже если их не использует ни один процесс. Прежде чем удалить постоянный объект, ОС должна сделать его временным.)

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

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

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

2.2.2 Учет использования ресурсов

Учет использования ресурсов, так же как и удержание объектов, тесно связан с использованием описателей объектов. Если у объекта есть положительный счет­чик открытых описателей, это означает, что некоторый процесс использует данный ресурс. Это также означает, что некоторый процесс "платит" за память, занятую объектом. Когда счетчик описателей объекта обнуляется, процесс, пе­ред тем использовавший объект, не должен более за это платить.

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

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

2.3 Методы объектов

Диспетчер объектов использует их сходные черты, чтобы работать с объектами единообразно. Однако, у объектов есть и различия, иногда весьма существенные. Диспетчер объектов был бы слишком большим и сложным, если бы ему при­шлось учитывать все особенности различных типов объектов. Он также должен был бы изменяться при добавлении к системе нового типа объектов. Чтобы из­бежать этого, диспетчер объектов предоставляет возможности перехвата, кото­рые другие компоненты исполнительной системы NT могут использовать для выполнения задач, уникальных для их типов объектов. Эти средства перехвата называются методами объектов (object method).

Когда компонент исполнительной системы создает новый тип объекта, он может зарегистрировать в диспетчере объектов один или несколько мето­дов. После этого диспетчер объектов вызывает данные методы в строго определенные моменты жизни объекта этого типа: обычно, когда объект создается;

удаляется или некоторым образом модифицируется. Методы, поддерживаемые диспетчером объектов, перечислены в табл. 5.

Таблица 5. Методы объектов

Метод	Когда вызывается
Открыть	При открытии описателя объекта
Закрыть	При закрытии описателя объекта
Удалить	Прежде чем диспетчер объектов удалит объект
Запросить имя	Когда поток запрашивает имя объекта, который находится во вторичном домене объектов, например файла
Разбор	При поиске диспетчером объектов имени объекта, существующего во вторичном домене объектов
Защита	При считывании или изменении процессом параметров защиты объекта, который находится во вторичном домене объектов, например файла

Пример использования метода "закрыть" имеет место в системе ввода-вы­вода. Диспетчер ввода-вывода регистрирует метод закрытия для файлового типа объектов, а диспетчер объектов вызывает данный метод всякий раз, когда он зак­рывает описатель файлового объекта. Метод "закрыть" проверяет, установлены ли процессом, закрывающим файл, какие-либо блокировки этого файла, и если да, то удаляет их. Проверка на наличие блокировок файла не является действием, ко­торое может или должен осуществлять непосредственно диспетчер объектов.

Перед удалением из памяти временного объекта диспетчер объектов вы­зывает метод "удалить", если он был зарегистрирован. Диспетчер виртуальной. памяти для объектов типа "секция", например, регистрирует данный метод, ко­торый освобождает физические страницы, занятые секцией. Метод также гаран­тирует, что все внутренние структуры данных, выделенные для секции диспетче­ром виртуальной памяти, будут удалены перед удалением объекта—секции. Эту работу тоже не может выполнить диспетчер объектов, так как он ничего не зна­ет о внутренних принципах работы диспетчера виртуальной памяти. Методы удаления для других типов объектов выполняют аналогичные функции.

Метод "разбор" (и аналогично, метод "получить имя") позволяет диспет­черу объектов переложить задачу поиска объекта на вторичный диспетчер объектов. Вторичный диспетчер объектов находит объект, расположенный вне пространства имен диспетчера объектов, в другом домене объектов. Простей­шим примером является система ввода-вывода. Посмотрим еще раз на рисунок (справа), который уже приводился выше.

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

При создании типового объекта "устройство" система ввода-вывода ре­гистрирует для него метод "разбор". Когда диспетчер объектов ищет им объекта, он приостанавливает поиск, если ему встречается объект, имеющий метод разбора. Диспетчер объектов вызывает метод "разбор", передавая ему остаток имени объекта, которое нужно найти.

Пространство имен

Диспетчера объектов.

 

Пространство

имен

файловой

системы.

Например, когда процесс открывает описатель объекта с именем \Devi-ce\FloppyO\docs\resume. doc, диспетчер объекта проходит по своему дереву имен, пока не достигнет объекта-устройства с именем FloppyO. Он обнаруживает, что с этим объектом связан метод "разбор", и вызывает данный метод, переда­вая ему остаток имени объекта, которое он ищет — в данном случае строку \docs\resumc. doc. Метод разбора для объектов-устройств — это процедура вво­да-вывода. Процедура принимает строку имени и передает ее подходящей фай­ловой системе, которая находит файл на диске и открывает его.

Объекты - символические связи также транс­лируются методом "разбор". У типа объектов "символическая связь" имеется свой такой метод. Метод получает имя, подставляет вместо него другое и вызы­вает диспетчер объектов для повторного поиска объекта. (Если в новом имени также имеется символическая связь, то метод "разбор" будет вызван еще раз.)

Метод "защита", который используется системой ввода-вывода, похож на метод "разбор". Он вызывается всякий раз, когда поток пытается изменить ин­формацию о защите файла. Эта информация для файлов имеет отличия по срав­нению с другими объектами, так как хранится в самом файле, а не в памяти. Таким образом, для поиска и изменения информации о защите должна быть вызвана система ввода-вывода.

3. Защита объектов

Унификация именования, предоставления в совместное использование и учета использования системных ресурсов уже дает достаточные основания для при­менения объектной модели в исполнительной системе NT; однако важнейшей причиной этого, является, по всей вероятности, обеспечение защиты.

Операционная система должна быть защищена от "нападений" сразу на нескольких фронтах. Защищенная многопользовательская система должна защищать файлы, память и другие ресурсы каждого пользователя от других пользователей. Она должна защищать собственные данные, файлы и память от пользовательских программ. Она должна отслеживать попытки обхода защиты и т. д. Министерство обороны США определило средства, наличие которых у ОС делает ее защищенной. Эти средства разделены на семь уровней защиты, причем каждый последующий более строг, чем предыдущий[8].

Для соответствия уровню С2, исходной цели для Windows NT, в ней долж­ны присутствовать следующие средства:

·  Средство защищенной регистрации в системе требует, чтобы пользо­ватель идентифицировал себя посредством ввода уникального иденти­фикатора и пароля, прежде чем ему будет предоставлен доступ к системе,

·  Селективный контроль доступа позволяет владельцу ресурса опреде­лять, кто имеет доступ к данному ресурсу и что они могут с ним делать, Владелец определяет это, назначая права доступа пользователю или группе пользователей.

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

·  Защита памяти предотвращает чтение информации, записанной кем-либо в память, после того как этот блок памяти был возвращен ОС, Перед повторным использованием память реинициализируется.

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

В тех случаях, когда предъявляются особые требования к безопасности, например, в военных организациях, необходим еще более высокий уровень за­щиты, чем тот, что исходно обеспечивается Windows NT. В связи с этим Windows NT рассчитана на дальнейшее развитие до уровня защиты В 2, известного под названием " Полномочный контроль доступа" (Mandatory Access Control), когда каждому пользователю присваивается уровень полномочий и он не может пре­доставить доступ к защищенным ресурсам пользователям с недостаточным уровнем полномочий. Например, в секретных учреждениях правительства США одному пользователю может быть присвоен уровень полномочий "Секретно", а другому — "Совершенно секретно". Полномочный контроль доступа гарантиру­ет, что пользователь с уровнем полномочий "Совершенно секретно" не сможет предоставить первому пользователю доступ к какой-либо информации с гри­фом "Совершенно секретно", даже при помощи средств селективного контроля доступа. Кроме того, уровень В2 требует поддержки "отделений" (compart­ments), изолирующих группы пользователей друг от друга. Этот тип защиты удобен в таких областях, как торговля ценными бумагами, где неавторизованный доступ к информации о предложении акций или слиянии может вызвать конфликт интересов.

Система защиты Windows NT многогранна, однако, суть селективного контроля доступа и аудита (а в будущем и полномочного контроля доступа) состоит в защите объектов. Главная идея, лежащая в основе системы защиты Windows NT, — это создание шлюза, через который должен пройти каждый пользователь системных ресурсов. Так как все системные ресурсы, защита ко­торых может быть нарушена, реализованы как объекты, то таким шлюзом ста­новится диспетчер объектов. Чтобы удостовериться в целостности системы за­щиты Windows NT, нет необходимости тыкаться во все "закоулки" ОС; крити­ческие операции обеспечения защиты выполняются в одном центре.

Следующие подразделы рассматривают защиту объектов с двух точек зре­ния: во-первых, идентификация пользователей, во-вторых, управление досту­пом пользователей к объектам.

3.1 Маркеры доступа

Чтобы контролировать, кто имеет право работать с объектом, система защиты должна быть уверена, что пользователь правильно идентифицирован. Таким образом, первая линия защиты в Windows NT — это требование, чтобы каждый пользователь зарегистрировался перед началом работы.

Как описано в гл. 2, "Общие сведения о системе", неотъемлемая часть сис­темы — защищенная подсистема, известная как подсистема защиты (security subsystem), отвечает за аутентификацию (authenticating) пользователей, т. е. за проверку того, что введенная пользователем при регистрации в системе инфор­мация совпадает с информацией, хранящейся в базе данных защиты. После того, как подсистема защиты определила, что регистрация аутентична, она создает объект, который остается постоянно связанным с пользовательским процессом. Этот объект называется маркером доступа (access token) и служит официаль­ным удостоверением личности процесса, когда тот пытается использовать ка­кой-либо системный ресурс. Пример маркера доступа показан на рис. 3-9.

Первый показанный на рисунке атрибут — это личный пользовательский идентификатор защиты (security ID), который обычно соответствует иденти­фикатору, указываемому пользователем при регистрации. В больших организа­циях идентификатор защиты также может включать в себя название подразделения или отдела пользователя (например, ENGINEERING_MARYH).

 

Рис.9. пример маркера доступа.

Идентифи­каторы защиты групп создаются из списков идентификаторов пользователей, Второй атрибут на рис. 3-9 — это список групп, к которым принадлежит MARYH. Windows NT задает несколько стандартных идентификаторов групп, которые включены в маркер MARYH.

При попытке процесса открыть описатель объекта диспетчер объектов вызывает справочный монитор защиты. Справочный монитор защиты получает маркер доступа, связанный с процессом, и использует его идентификатор защи­ты и список групп, чтобы определить, имеет ли процесс право доступа к объекту.

Небольшое количество чувствительных к защите системных сервисов (та­ких как создание маркера), также защищены от использования. Атрибут приви­легий перечисляет все такие сервисы, к которым имеет право обращаться пользователь. Большинство пользователей не имеет никаких привилегий.

В общем случае, пользователь, создавший объект, становится его владель­цем и может решать, кто еще имеет доступ к объекту. Список контроля доступа (access control list, ACL) по умолчанию, хранящийся в маркере доступа, — это первоначальный список прав доступа, который присоединяется к создаваемым пользователем объектам. Атрибут "первичная группа" позволяет собирать иден­тификаторы защиты в группы для организационных целей. Это свойство при­сутствует в некоторых средах ОС, включая POSIX.

Более подробно идентификаторы защиты и списки управления доступом описаны в следующем разделе. Теперь же обратимся к рис.10, где изображены атрибуты и сервисы, применимые к объектам-маркерам доступа.

К сервисам создания, открытия и опроса добавляется еще сервис уста­новки. Установка атрибутов объекта — это распространенный сервис, предос­тавляемый многими объектами исполнительной системы NT. Другие три сер­виса предназначены для использования главным образом программами адми­нистрирования защиты.

Рис.10. Объект-маркер доступа

3.2 Списки контроля доступа

При создании любого объекта, включая файлы, потоки, события и даже марке­ры доступа, ему присваивается дескриптор защиты[9]. Основной частью деск­риптора защиты является список прав доступа к объекту, называемый списком контроля доступа (ACL). Владелец объекта, которым обычно является его со­здатель, обладает правом селективного контроля доступа к объекту и может изме­нять ACL объекта, чтобы разрешить или запретить другим его использование. На рис. 3-11 упрощенно изображен файловый объект и его ACL.

Каждый вход ACL называется элементом контроля доступа (access control entry, АСЕ). АСЕ содержит идентификатор защиты и набор прав доступа. Пользо­вателю с соответствующим идентификатором защиты перечисленные права доступа могут быть разрешены, запрещены или разрешены с аудитом. Сумма прав доступа, предоставленных отдельными АСЕ, формирует набор прав досту­па, предоставляемых ACL

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

Как показано на рис. 3-11, АСЕ может также содержать идентификатор защи­ты группы. DAVEC имеет доступ к файловому объекту по чтению, члены группы TEAM 1 — по чтению и записи, а все другие пользователи — права на исполнение.

 

рис.11. Список контроля доступа ACL

Чтобы определить, какой ACL должен быть назначен новому объекту, система защиты применяет три взаимоисключающих правила, в приведенном ниже порядке:

·  Если ACL явно задан при создании объекта, то система защиты присва­ивает объекту данный ACL.

·  Если ACL не задан и у объекта есть имя, то система защиты ищет АСL каталога объектов, в котором будет сохранено имя нового объекта. Не­которые АСЕ каталога объектов могут быть обозначены как "наследуе­мые" — это означает, что они должны быть присвоены новым объектам созданным в данном каталоге. Если такие наследуемые АСЕ присутству­ют, то система защиты составляет из них ACL, который она назначает новому объекту.

·  Если ни один из первых двух случаев не имеет места, то система защита присваивает новому объекту ACL по умолчанию из маркера доступа вызывающего процесса.

Кроме ACL, дескриптор защиты объектов содержит поле, управляющее аудитом объекта. Аудит (auditing) означает способность системы защиты "шпи­онить" за выбранными объектами и их пользователями и генерировать сообще­ния или оповещения, если кто-либо попытается выполнить над объектом опе­рацию, использование которой ограничено. Например, система защиты может выполнять аудит попыток чтения или изменения системного файла. Если кто-то пытается модифицировать данный файл, то система защиты помещает сооб­щение в журнал аудита вместе с идентификатором защиты пользователя. Сис­темный администратор может генерировать отчеты, составленные по инфор­мации из этого журнала. Для систем с очень высоким уровнем защиты система защиты может даже генерировать звуковые или визуальные сигналы тревоги на машине администратора, когда происходит некоторое действие. Аудит умень­шает риск незаконного проникновения в компьютер.

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

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

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

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

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

 

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

Однако из-за порядка расположения АСЕ в ACL в данном случае третий АСЕ игнорируется. (Это несколько надуманный пример, так как система в общем случае помещает АСЕ, запрещающие до­ступ, в начало списка.)

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

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

Заметьте, что после того, как процесс успешно открыл описатель, предо­ставленные ему права доступа не могут быть отозваны системой защиты, даже

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

4. Заключение

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

Объекты пользовательского режима, представленные в этой главе, основа­ны на наборе более примитивных объектов, реализованных ядром NT.

5. Литература

1.  Хелен Кастер “Основы Widows NT и NTFS”. Бином; 1998

2.  , Молчанов программное обеспечение (учебник). – Спб: 2001.

3.  Коваленко вычислительных процессов и структур: Учебное пособие. – Краснодар: Изд-во КубГТУ, 1999. – 118с.

4.  www.

[1] При создании объекта при помощи API Win32 либо базовых объектных сервисов вызывающая программа передаст параметр под названием OhjectAltributes (Атрибуты Объекта), но его не сле­дует смешивать с более общим значением данного термина, которое используется в этой книге.

[2] Имя мутант имеет интересную историю. В начале разработки Windows NT Дэйв Катлер со­здал объект ядра — мьютекс, реализующий низкоуровневое взаимное исключение. Позднее он обнаружил, что OS/2 требует для взаимного исключения версии семафора, имеющей дополни­тельную семантику, которую Дэйв посчитал "повреждающей рассудок" и которая оказалась не­совместимой с первоначальным объектом (конкретно, ноток мог покинуть объект и оставить его в недоступном состоянии). Тогда Дэйв создал версию мыотекса для OS/2 и дал ей имя му­тант. Позднее он изменил объект-мутант, чтобы устранить зависимость от OS/2 и дать возмож­ность использовать этот объект системе Win32. В API Win32 модифицированный объект называ­ется мьютекс, но в базовых сервисах сохранилось имя мутант.

[3] В Windows NT версии 3.51 Service Pack 3 добавлен новый объект — ожидающий таймер. Подроб­нее см. сноску в следующей главе.

[4] Подсистема Win32 позволяет прикладному процессу назначать объектам дескрипторы защиты, но не требует этого. Если дескриптор защиты не назначен приложением, то подсистема Win32 делает это за него.

[5] Это упрощенное представление об истинном механизме сохранения, который более подробно описан далее в этой главе.

[6] Такое изображение объектов является упрощенной версией формата, предложенного Питером Ко­дом и Эдвардом Йордоном в книге Object-Oriented Analysis (Englewood Clifis, N. J.: Prentice—Hall, 1990).

[7] упрощенное описание механизма, рассматриваемого в следующем разделе

[8] Department of Defense Trusted Computer System Evaluation Criteria, DOD 5200.28-STD (December 1985)

[9] Из этого правила есть исключения. Дескрипторы защиты необходимы только тем объемам, кото­рые будут использоваться более чем одним процессом. К этой группе относятся все поименованные объекты, а также как поименованные, так и безымянные процессы, потоки и маркеры.