Организация контроля доступа к файлам.

 Файлы – это самый популярный вид разделяемых ресурсов, доступ к которым ОС должна контролировать

• Различают два основных подхода к определению прав доступа:

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

– мандатный подход, когда система наделяет пользователя определенными правами по отношению к файлу в зависимости от того, к какой группе пользователь отнесен

 

Определить права доступа к файлу – значит определить для каждого пользователя ограниченный набор

операций, которые он может применить к данному файлу

• В разных ФС может быть определен свой список операций доступа

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

файлам системы, строки – всем пользователям

• На пересечении строк и столбцов указываются разрешенные операции

В некоторых системах пользователи могут быть разделены на категории

• Для всех пользователей одной категории определяются единыеправа доступа

• Например, в *nix-системах все пользователи подразделяются на три категории: владельца файла,

членов его группы и всех остальных

 

Матрица прав доступа хранится по частям

• Для каждого файла или каталога создается список управления доступом (ACL)

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

этому файлу или каталогу

• Список управления доступа является частью характеристик файла или каталога и хранится на диске в

соответствующей области

 

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

• Список ACL состоит из элементов управления доступом (ACE), при этом каждый элемент соответствует одному идентификатору

• Список ACL с добавленным к нему идентификатором – характеристики безопасности

 

Поддержка нескольких файловых систем.

 Популярность той или иной ФС приводит к ее «миграции» из «родной» ОС в другие ОС

• Так, ФС FAT появилась в MS-DOS, затем была реализована в OS/2, семействе ОС Windows и даже во многих реализациях ОС Unix

• Поддержка нескольких популярных ФС для ПВВ также очень важна

• Не менее важно, чтобы архитектура ПВВ позволяла просто включать в ее состав новые ФС, без внесения изменений в код

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

решение данной задачи, например слой VFS в версиях Unix версии SVR4

 

Поддержка синхронных и асинхронных операций ввода-вывода

• Операция ввода-вывода (ОВВ) может выполняться по отношению к программному модулю, запросившему операцию, в синхронном и асинхронном режимах

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

• При асинхронном режиме модуль продолжает выполняться в мультипрограммном режиме

одновременно с ОВВ

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

 

Часть 6. Сетевые ОС

 46. Концепции распределенной обработки данных. Двухзвенные приложения.

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

 

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

Двухзвенные схемы

 

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

 

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

 

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

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

 

 В схеме «файловый сервер» (рис. 9.1, б) на клиентской машине выполняются все части приложения, кроме файловых операций. В сети имеется достаточно мощный компьютер, имеющий дисковую подсистему большого объема, который хранит файлы, доступ к которым необходим большому числу пользователей. Этот компьютер играет роль файлового сервера, представляя собой централизованное хранилище данных, находящихся в разделяемом доступе. Распределенное приложение в этой схеме мало отличается от полностью локального приложения. Единственным отличием является обращение к удаленным файлам вместо локальных. Для того чтобы в этой схеме можно было использовать локальные приложения, в сетевые операционные системы ввели такой компонент сетевой файловой службы, как редиректор, который перехватывает обращения к удаленным файлам (с помощью специальной нотации для сетевых имен, такой, например, как //server"!/doc/file1.txt) и направляет запросы в сеть, освобождая приложение от необходимости явно задействовать сетевые системные вызовы.

 

Файловый сервер представляет собой компонент наиболее популярной сетевой службы — сетевой файловой системы, которая лежит в основе многих распределенных приложений и некоторых других сетевых служб. Первые сетевые ОС (NetWare компании Novell, IBM PC LAN Program, Microsoft MS-Net) обычно поддерживали две сетевые службы — файловую службу и службу печати, оставляя реализацию остальных функций разработчикам распределенных приложений.

 

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

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

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

 

 Другие варианты двухзвенной модели более равномерно распределяют функции между клиентской и серверной частями системы. Наиболее часто используется схема, в которой на серверный компьютер возлагаются функции проведения внутренних операций базы данных и файловых операций (рис. 9.1, в). Клиентский компьютер при этом выполняет все функции, специфические для данного приложения, а сервер — функции, реализация которых не зависит от специфики приложения, из-за чего эти функции могут быть оформлены в виде сетевых служб. Поскольку функции управления базами данных нужны далеко не всем приложениям, то в отличие от файловой системы они чаще всего не реализуются в виде службы сетевой ОС, а являются независимой распределенной прикладной системой. Система управления базами данных (СУБД) является одним из наиболее часто применяемых в сетях распределенных приложений. Не все СУБД являются распределенными, но практически все мощные СУБД, позволяющие поддерживать большое число сетевых пользователей, построены в соответствии с описанной моделью клиент-сервер. Сам термин «клиент-сервер» справедлив для любой двухзвенной схемы распределения функций, но исторически он оказался наиболее тесно связанным со схемой, в которой сервер выполняет функции по управлению базами данных (и, конечно, файлами, в которых хранятся эти базы) и часто используется как синоним этой схемы.

 

⇐ Предыдущая234567891011Следующая ⇒

Поделиться: