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

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

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

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

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

Во многих операционных системах существует особый пользователь (superuser, root, administrator, администратор), который имеет все права по отношению к любым объектам системы, не обязательно являясь их владельцем.

Каждый пользователь и каждая группа пользователей обычно имеют символьное имя (часто называемое логином), назначаемое администратором, а также уникальный числовой идентификатор (ID), присваиваемый им операционной системой.

При выполнении процедуры логического входа в систему пользователь сообщает свое символьное имя и пароль, а операционная система определяет соответствующие числовые идентификаторы пользователя и групп, в которые он входит. Все идентификационные данные, в том числе имена и идентификаторы пользователей и групп, пароли пользователей, а также сведения о вхождении пользователя в группы хранятся в специальном файле (файл /etc/passwd в UNIX) или в специальной базе данных (в Windows семейства NT).

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

Пример матрицы прав доступа к файлам

Практически во всех операционных системах матрица прав доступа хранится «по частям», т. е. для каждого файла или каталога создается так называемый список управления доступом (Access Control List, ACL), в котором описываются права на выполнение операций пользователей и групп пользователей по отношению к этому файлу и каталогу.

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

Распределенная обработка данных в сетевых операционных системах [1, тема 3].

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

Распределенные приложения могут обладать рядом преимуществ по сравнению с локальными:

• более высокая производительность;

• отказоустойчивость;

• масштабируемость;

• приближение к пользователю.

Следует выделить три основных параметра организации работы приложений в сети:

• способ разделения приложения на части, выполняющиеся на разных компьютерах сети;

• выделение специализированных серверов в сети, на которых выполняются некоторые общие для всех приложений функции;

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

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

На рис. 3.1 представлены варианты распределения частей приложения по двухзвенной схеме (между двумя компьютерами).

Рис. 3.1. Варианты распределения частей приложения по двухзвенной схеме

В централизованной схеме (рис. 3.1, а) компьютер пользователя работает как терминал, выполняющий лишь функции представления данных, а все остальные функции передаются центральному компьютеру – серверу.

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

Основные недостатки: слабая масштабируемость (количество одновременно работающих пользователей определяется производительностью сервера) и низкая отказоустойчивость.

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

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

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

В варианте (рис. 3.1, в) нагрузка между компьютерами распределяется более равномерно. На серверный компьютер возлагаются функции проведения внутренних операций базы данных и файловые операции. Клиентский компьютер при этом выполняет все функции, специфические для данного приложения, а сервер – функции, реализация которых не зависит от специфики приложения, из-за чего эти функции могут быть оформлены в виде сетевых служб. Поскольку функции управления базами данных нужны далеко не всем приложениям, то в отличие от файловой системы они чаще всего не реализуются в виде службы сетевой операционной системы, а являются независимой распределенной прикладной системой.

Система управления базами данных (СУБД) является одним из наиболее часто применяемых в сетях распределенных приложений.

Термин «клиент-сервер» справедлив для любой двухзвенной схемы распределения функций, но исторически он чаще применяется для варианта, в котором сервер выполнял функции по управлению базами данных и поэтому часто используется как синоним этой схемы.

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

Рис. 3.2. Вариант трехзвенной схемы распределения частей приложения

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

Механизм организации взаимодействия в распределенных системах

В общем случае межпроцессное взаимодействие может осуществляться одним из двух способов:

• с помощью совместного использования одних и тех же данных (разделяемая память);

• путем передачи друг другу данных в виде сообщений.

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

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

В сообщениях переносятся запросы от клиентов некоторых служб к соответствующим серверам. Сервер возвращает ответ, также помещая его в сообщение и отправляя его по сети клиенту.

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

В любой сетевой ОС в составе подсистемы ввода-вывода имеется подсистема передачи сообщений, называемая также транспортной подсистемой, которая обеспечивает организацию взаимодействия процессов в сети. Назначение этой подсистемы – экранирование деталей сложных сетевых протоколов от программиста.

Транспортная подсистема позволяет процессам взаимодействовать посредством достаточно простых примитивов. В самом простом случае системные средства обеспечения связи могут быть сведены к двум основным коммуникационным примитивам, один send (отправить) – для посылки сообщения, другой receive (получить) – для получения сообщения.

При этом процесс выполнения примитивов send и receive вовлекает в работу средства всех нижележащих коммуникационных протоколов (рис. 3.3).

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

Для идентификации компьютеров используется система IP-адресов.

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

Ввиду повсеместного применения стека протоколов TCP/IP на сегодня наиболее популярными адресами служб в системах обмена сообщениями сетевых ОС являются номера портов TCP/UDP. Порт TCP/UDP является не только абстрактным адресом службы, но и представляет собой нечто более конкретное – для каждого порта операционная система поддерживает буфер в системной памяти, куда помещаются отправляемые и получаемые сообщения, адресуемые данному порту.

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

Централизованная служба имен предполагает наличие специализированных серверов, хранящих базу данных соответствия между символьными именами и числовыми адресами. Эти серверы образуют распределенную службу имен, обрабатывающую запросы многочисленных клиентов. Хорошим примером такой службы является служба доменных имен Интернета (Domain Name Service, DNS).

Централизованная служба имен на сегодня считается наиболее перспективным средством повышения прозрачности услуг для пользователей сетей. С такой службой связывают и перспективы дальнейшего повышения прозрачности адресов сетевых ресурсов, когда имя ресурса будет полностью независимо от компьютера, предоставляющего этот ресурс в общее пользование. Например, в службе каталогов (NetWare Directory Services, NDS) компании Novell уже сегодня можно использовать такие имена, как имена томов, не указывая их точного расположения на том или ином компьютере.

Еще одним удобным механизмом, облегчающим взаимодействие операционных систем и приложений по сети, является механизм вызова удаленных процедур (Remote Procedure Call, RPC).

Когда вызываемая процедура действительно является удаленной, в библиотеку процедур вместо локальной реализации оригинального кода процедуры помещается другая версия процедуры, называемая клиентским стабом (stab – заглушка). На удаленный компьютер, который выполняет функцию сервера процедур, помещается оригинальный код вызываемой процедуры, а также еще один стаб, называемый серверным стабом.

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

Стабы используют для передачи данных через сеть средства подсистемы обмена сообщениями, т. е. существующие в операционной системе примитивы send и receive.

Назначение и принципы построения службы каталогов в компьютерных сетях [1, тема 3].

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

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

Служба каталогов может решать следующие задачи:

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

• Распределять каталог по различным компьютерам сети.

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

• Разбивать каталог на несколько разделов для обеспечения возможности хранения большого количества объектов.

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

Active Directory – это служба каталогов, включенная в операционную систему Windows 2000/2003 Server.

Служба каталогов Active Directory обеспечивает безопасность, распределенность, возможность разбиения на разделы и возможность репликации.

Служба каталогов Active Directory образует пространство имен, в котором имя объекта в каталоге разрешается в сам объект.

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

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