Операционные системы

частности, таблица файловых дескрипторов. Она, как и все таблицы в

системе UNIX, позиционная, т.е. номер дескриптора соответствует

номеру записи в этой таблице. С файловым дескриптором (ФД)

ассоциировано имя файла и все необходимые атрибуты для работы с ним.

Номера ФД уникальны в пределах одного процесса. Есть аналогичная

функция create - функция открытия нового файла.

2. read/write - системные вызовы чтения/записи, параметрами которых

является номер ФД и некоторые атрибуты, которые не так важны для

нашего рассмотрения.

3. close - системный вызов завершения работы с файлом, параметром

которого является номер ФД. После обращения к этой функции ФД

становится свободным, а работа данного процесса с файлом завершается.

Вот некоторые системные вызовы, обеспечивающие ввод/вывод (кстати, они

почти не добавляют кода к вашей программе). Подробности посмотрите

самостоятельно. Я обратил ваше внимание, что это системные вызовы, потому

что ввод/вывод можно осуществлять и через библиотеки ввода/вывода. Для

этого существует, так называемый, файловый обмен и функции fopen, fread, и

т.д. (с префиксом f). Это библиотечные функции. Эти функции сами обращаются

к низкоуровневым функциям внутри себя.

Рассмотрим организацию обмена с системной точки зрения в операционной

системе UNIX. При организации обмена операционная система подразделяет

данные на две категории: данные, ассоциированные с процессом пользователя,

и данные, ассоциированные с операционной системой.

Таблица индексных дескрипторов открытых файлов. Первая таблица данных,

ассоциированных с операционной системой, - таблица индексных дескрипторов

открытых файлов (ТИДОФ). Эта таблица содержит записи, каждая из которых

содержит копию индексного дескриптора для каждого открытого в системе

файла. Через эту копию осуществляется доступ к блокам файлов. Каждая

записей таблицы содержит также поле, характеризующее количество открытых в

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

один и тот же файл открыт от имени двух процессов, то запись в ТИДОФ

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

счетчик на единицу.

Таблица файлов. Таблица файлов (ТФ) содержит информацию об имени

открытого файла, и имеет ссылку на ТИДОФ.

Лекция №9

Мы говорили, что система может работать с содержимым файла в том и

только том случае, если процесс зарегистрировал свое желание работать с

этим файлом. Факт такой регистрации называется открытием файла. При

открытии файла в пределах процесса каждому имени открываемого файла

(открываться может уже существующий файл, либо новый) ставится в

соответствие уникальное целое число, которое называется файловым

дескриптором (ФД). В пределах процесса ФД имеют нумерацию от 0 до k-1.

Значение k - это параметр настройки операционной системы, определяющий,

какое количество одновременно открытых файлов может быть у процесса. Здесь

следует отметить, что мы говорим о количестве одновременно открытых файлов

(так же написано в любой книжке по UNIX-у), однако, на самом деле, k - это

максимальное количество ФД, которые могут быть ассоциированы с одним

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

раза, и образуется два ФД. К чему это приведет, мы рассмотрим несколько

позже, но это вполне корректно. После открытия файла, все операции обмена

осуществляются через указания файлового дескриптора (т.е. имя более нигде

не указывается). С каждым файловым дескриптором ассоциирован ряд параметров

(о них чуть позже).

Давайте посмотрим, как организуется ввод/вывод, а точнее обработка

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

рассказано о логической схеме организации ввода/вывода, ибо реальная схема

устроена несколько иначе, но это для нас не так важно.

Все данные, с которыми оперирует система, подразделяются на два

класса. Первый тип данных - данные, ассоциированные с операционной

системой, то есть общесистемные данные. К этим данным относится ТИДОФ.

Размер таблицы фиксирован и определяется количеством одновременно открытых

ФД. Каждая запись в этой таблице содержит некоторую информацию, среди

которой нас будет интересовать следующая:

1) Копия ИД открытого файла. Для любого открытого файла, ИД, который

характеризует содержимое этого файла, копируется и размещается в

ТИДОФ. После этого все манипуляции с файлом (например, изменение

адресации файла) происходят с копией ИД, а не с самим ИД на диске.

ТИДОФ размещается в оперативной памяти, т.е. доступ к информации в

ней осуществляется быстро.

2) Счетчик открытых в данный момент файлов, связанных с данным ИД. Это

означает, что для любого количества открытий файла, связанного с

данным ИД, система работает с единственной копией этого ИД.

Теперь перейдем к, так называемой, таблице файлов (ТФ). Таблица файлов

состоит из фиксированного количества записей. Каждая запись ТФ

соответствует открытому в системе файлу {{или точнее ФД}}. При этом в

подавляющем большинстве случаев это есть взаимно однозначное соответствие.

Тот случай, когда это не есть взаимно однозначное соответствие, мы

рассмотрим ниже. Каждая запись ТФ содержит указатели чтения/записи по

файлу. Это означает, что, если открыт один и тот же файл в двух процессах

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

они друг от друга не зависят (почти всегда, за исключением некоторых

случаев). Каждая запись ТФ содержит, так называемый, индекс

наследственности - это есть некоторое целое число.

Это данные уровня операционной системы, т.е. данные, которые описывают

состояние проблемы в системе в целом.

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

(ТОФ). Номер записи в данной таблице есть номер ФД. Каждая строка этой

таблицы имеет ссылку на соответствующую строку ТФ. Это означает, что

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

стороны, файловые дескрипторы - это данные, являющиеся атрибутом процесса,

с другой стороны, указатель - это данные, являющиеся атрибутом операционной

системы. Казалось бы, не логично, и сейчас мы рассмотрим, в чем эта

нелогичность проявляется. Для этого кратко рассмотрим концептуальные

вопросы, связанные с формированием процесса. Операционная система UNIX

имеет функцию fork(). Это системный вызов. При обращении к этому системному

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

вас может показаться бессмысленным, - происходит копирование процесса, в

котором встретилась эта функция, т.е. создается процесс-двойник. Для чего

это нужно, я скажу несколько позже.

Формирование процесса-двойника обладает следующими свойствами. Первое

свойство: процесс-сын, который будет сформирован после обращения к функции

fork(), имеет все те файлы, которые были открыты в процессе-отце. Второе -

система позволяет некоторыми своими средствами, идентифицировать, где

процесс-отец, а где процесс-сын, хотя в общем случае они абсолютно

одинаковы.

Предположим, есть процесс №1, и с ним ассоциирована таблица открытых

файлов №1. В этом процессе открыт файл с именем Name, и этому файлу

поставлен в соответствие файловый дескриптор I. Это означает, что в

соответствующей строке ТОФ будет запись, имеющая ссылку на ТФ. В ТФ

определены какие-то атрибуты, связанные с открытием файла, а также имеется

указатель чтения/записи, т.е. тот указатель, по которому мы работаем,

обмениваясь информацией с файлом. Записи в ТФ имеют ссылку на ТИДОФ, в

которой находится копия ИД, соответствующего файлу с именем Name.

Предположим, что в этом процессе еще раз открыт файл с именем Name.

Система поставила ему в соответствие файловый дескриптор J. Т.е. этому

открытию соответствует J-тая строка ТОФ первого процесса. В этой записи

будет ссылка на запись ТФ, которая поставлена в соответствие второму

открытию файла Name. И пока индексы наследственности для обоих случаев

будут равны единице. В этой записи будут свои, связанные с этим открытием,

указатели чтения/записи. Указатели файловых дескрипторов I и J независимы

друг от друга, т.е. при чтении/записи через файловый дескриптор I,

указатель файлового дескриптора J не изменится. Эта запись будет ссылаться

на тот же самый индексный дескриптор из ТИДОФ, и значение счетчика будет

равно двум.

Предположим, процесс №1 выполнил обращение к функции fork(),

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

из fork(), и со вторым процессом будет ассоциирована ТОФ №2. Так же будет

открыт файл Name по ИД I и по ИД J. Но в этом случае, когда процесс получил

открытые файлы в наследство от родителя, то ссылки из соответствующих строк

ТОФ будут происходить не на новые записи ТФ, а на те же самые, к которым

ссылались соответствующие ФД у родителя. У этих процессов указатели чтения

записи будут одинаковы, т.е. если передвинуть указатель в одном процессе,

то он автоматически передвинется и для другого процесса. Этот случай, как

раз тот, когда нет взаимно однозначного соответствия между строками ТФ и

строками ТОФ. При порождении этих ссылок счетчик увеличивается на два. И,

соответственно, из ИД, за счет адресации блоков, осуществляется доступ к

блокам файлов. Такая информационная организация обмена означает, что обмен

с содержимым каждого файла осуществляется централизованно, т.е. в конечном

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

файлов, связанных с этим ИД, не было открыто в системе. Здесь нет никаких

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

невыполненных обменах, связанных с одним дескриптором.

При любом формировании нового процесса, система априори устанавливает

нулевой, первый и второй файловые дескрипторы из ТОФ, связывая их с

предопределенными файлами. Нулевой ФД связан с системным файлом ввода, с

ним обычно ассоциировано внешнее устройство клавиатура. Первый ФД - это

стандартный файл вывода, обычно с ним ассоциирован экран монитора. Второй

ФД - это стандартный файл вывода диагностических сообщений, с ним также

обычно ассоциирован экран монитора.

Рассмотрим для примера типовые действия при обращении к тем или иным

системным вызовам.

Обращение к функции fork(). Как известно, при обращении к этой функции

система создает копию исходного процесса. При этом система дублирует ТОФ

одного процесса в ТОФ процесса-наследника, а также увеличивает на единицу

индекс наследственности в строках ТФ, ассоциированных с открытыми файлами

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

данным ИД, в ТИДОФ.

Обращение к функции open(). При обращении к этой функции происходит

следующее:

1. По полному имени определяется каталог, в котором размещен

файл.

2. Определяется номер ИД. По номеру ИД осуществляется поиск в

таблице ТИДОФ.

3. Если запись с заданным номером обнаружена, фиксируем номер

соответствующей строки ТИДОФ и переходим к шагу 5.

4. В случае если строка не обнаружена, происходит формирование

новой строки, соответствующей новому ИД и фиксируется ее

номер.

5. Корректируем счетчик ссылок (стрелок) на запись ТИДОФ. Номер

записи в ТИДОФ записывается в запись ТФ, а также в ТОФ

устанавливается ссылка на соответствующую запись ТФ. После

этого в программу возвращается номер сроки ТОФ, в которой

находится ссылка на запись в ТФ.

При операциях ввода/вывода действия системы очевидны.

Взаимодействие с устройствами. Мы уже говорили, что все устройства,

которые обслуживаются операционной системой UNIX, могут быть

классифицированы на два типа - байт-ориентированные устройства и блок-

ориентированные устройства. Следует отметить, что одно и то же устройство в

системе может рассматриваться и как байт-ориентированное, и как блок-

ориентированное (пример - оперативная память). Соответственно, есть

драйверы блок-ориентированные и байт-ориентированные. На прошлой лекции мы

рассматривали специальные файлы, ассоциированные с внешними устройствами, и

говорили о том, что есть таблица драйверов блок-ориентированных устройств

и таблица драйверов байт-ориентированных устройств. Соответственно, на эти

таблицы имеются ссылки в ИД специальных файлов.

Основной особенностью организации работы с блок-ориентированными

устройствами является возможность буферизации обмена. Суть заключается в

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

каждый буфер имеет размер в один блок. Каждый из этих блоков может быть

ассоциирован с драйвером одного из физических блок-ориентированных

устройств.

Рассмотрим, как выполняется последовательность действий при исполнении

заказа на чтение блока. Будем считать, что поступил заказ на чтение N-ого

блока из устройства с номером M.

1. Среди буферов буферного пула осуществляется поиск заданного

блока, т.е. если обнаружен буфер, содержащий N-ый блок М-ого

устройства, то фиксируем номер этого буфера. В этом случае,

обращение к реальному физическому устройству не происходит, а

операция чтения информации является представлением информации

из найденного буфера. Переходим на шаг 4.

2. Если поиск заданного буфера неудачен, то в буферном пуле

осуществляется поиск буфера для чтения и размещения данного

блока. Если есть свободный буфер (реально, эта ситуация

возможна только при старте системы), то фиксируем его номер и

переходим к шагу 3. Если свободного буфера не нашли, то мы

выбираем буфер, к которому не было обращений самое долгое

время. В случае если в буфере имеется установленный признак

произведенной записи информации в буфер, то происходит

реальная запись размещенного в буфере блока на физической

устройство. Затем фиксируем его номер и также переходим к

пункту 3.

3. Осуществляется чтение N-ого блока устройства М в найденный

буфер.

4. Происходит обнуление счетчика времени в данном буфере и

увеличение на единицу счетчиков в других буферах.

5. Передаем в качестве результата чтения содержимое данного

буфера.

Вы видите, что здесь есть оптимизация, связанная с минимизацией

реальных обращений к физическому устройству. Это достаточно полезно при

работе системы. Запись блоков осуществляется по аналогичной схеме. Таким

образом организована буферизация при низкоуровневом вводе/выводе.

Преимущества очевидны. Недостатком является то, что система в этом случае

является критичной к несанкционированным выключениям питания, т.е.

ситуация, когда буфера системы не выгружены, а происходит нештатное

прекращение выполнения программ операционной системы, что может привести к

потере информации.

Второй недостаток заключается в том, что за счет буферизации разорваны

во времени факт обращения к системе за обменом и реальный обмен. Этот

недостаток проявляется в случае, если при реальном физическом обмене

происходит сбой. Т.е. необходимо, предположим, записать блок, он

записывается в буфер, и получен ответ от системы, что обмен закончился

успешно, но когда система реально запишет этот блок на ВЗУ, неизвестно. При

этом может возникнуть нештатная ситуация, связанная с тем, что запись может

не пройти, предположим, из-за дефектов носителя. Получается ситуация, при

которой обращение к системе за функцией обмена для процесса прошло успешно

(процесс получил ответ, что все записано), а, на самом деле, обмен не

прошел.

Таким образом, эта система рассчитана на надежную аппаратуру и на

корректные профессиональные условия эксплуатации. Для борьбы с вероятностью

потери информации при появлении нештатных ситуаций, система достаточно

«умна», и действует верно. А именно, в системе имеется некоторый параметр,

который может оперативно меняться, который определяет периоды времени,

через которые осуществляется сброс системных данных. Второе - имеется

команда, которая может быть доступна пользователю, - команда SYNC. По этой

команде осуществляется сброс данных на диск. И третье - система обладает

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

набор действий, которые информацию восстановят или спорные блоки, которые

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

определенное место файловой системы. В этом месте их можно попытаться

проанализировать и восстановить вручную, либо что-то потерять. Наш

университет одним из первых в стране начал эксплуатировать операционную

систему UNIX, и сейчас уже можно сказать, что проблем ненадежности системы,

с точки зрения фатальной потери информации, не было.

Сегодня мы начинали разговор о том, что у нас есть системные вызовы и

библиотеки ввода/вывода. Еще одно средство, которое позволяет

оптимизировать работу системы, - это стандартная библиотека ввода/вывода,

связанная с include-файлом stdio.h. Суть концептуального обмена та же

самая, что и при организации низкоуровневого ввода/вывода. Разница в том,

что, если open() возвращает номер файлового дескриптора, fopen() возвращает

указатель на некоторую структуру специального типа FILE. Второе и основное

- это библиотека функций. Многие функции сервиса, которые предоставляет эта

библиотека, реализуются в пределах вашего адресного пространства. В

частности, такой функцией сервиса является еще один уровень буферизации

ввода/вывода. Суть его заключается в том, что на ресурсах процесса можно

выделить буфер, который будет работать аналогично буферному пулу

операционной системы и, который минимизирует обращение вашего процесса к

системным вызовам ввода/вывода. Понятно, что эта библиотека ввода/вывода

реализуется посредством программы, использующей системные вызовы

ввода/вывода. Это означает, что появляется фактор двойной буферизации, хотя

это увеличивает ненадежность.

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

к чтению или записи через библиотечные функции объемами данных в полблока

или в треть блока, и если эти части идут подряд, то система сама за счет

буферизации, собирает эти части и вместо нескольких обращений к системному

вызову выполняет только одно обращение. Это выгодно. Невыгодно то, что эта

буферизация организуется в пределах адресного пространства процесса со

всеми вытекающими последствиями (теряется синхронизация по обменам в том

случае, если с данным файлом через эту библиотеку работают другие процессы,

потому что в теле каждого процесса есть свой буфер, который может

аккумулировать эти данные и никакого единообразия, которое есть в

рассмотренной нами схеме, не получается). Тем не менее, стандартная

библиотека ввода/вывода есть удобный инструмент; она имеет также средства

блокировки этой буферизации.

Лекция №10

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

организацией функционирования файловой системы. Это системная организация

низкоуровнего обмена. Мы выяснили, что за счет организации данных,

операционная система UNIX достаточно простыми и «прозрачными» средствами

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

того же файла. Мы видели, что все открытия одного и того же файла (под

файлом мы понимаем не имя, а содержимое) в конечном итоге сводятся к работе

с единственной копией ИД. Мы с вами выяснили, что почти все открытия

файлов, связанные с одним ИД, порождают для процессов возможность работать

со своими указателями чтения/записи по файлом, за исключением случаев,

когда файл в процессе был получен через наследование, т.е. файл был получен

от процесса-отца через функцию fork() процессом-сыном.

Мы с вами выяснили, что система подразделяет обслуживаемые устройства

на два класса: блок-ориентированные и байт-ориентированные. Одно и то же

устройство может одновременно быть и байт-ориентированным, и блок-

ориентированным. Это зависит как от самого устройства, так и от наличия

драйверов - программ управляющих этим устройством. Примером такого

устройства является оперативная память.

Мы с вами рассмотрели принципы организации низкоуровнего обмена для

блок-ориентированных устройств, и в контексте этого мы познакомились со

средствами буферизации, которые применяются в ОС UNIX, суть которых

заключается в том, что по аналогии с буферами чтения/записи из оперативной

памяти (аппаратным средством), операционная система создает программные

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

физическому устройству. Этот механизм выгодно отличал и отличает ОС UNIX.

Здесь следует заметить, что буферизация обмена может быть многоуровневой.

Первый дополнительный уровень может появиться за счет того, что устройство

может иметь свои аппаратные буфера, реализованные по аналогии с буферами

оперативной памяти.

Мы также говорили о том, что кроме низкоуровнего ввода/вывода, с

которым связаны функции, обеспечивающие системные вызовы (open, read, write

и т.д.), существуют высокоуровневые средства доступа - это стандартная

библиотека ввода/вывода stdio.h, подключение которой позволяет использовать

для организации обменов еще один уровень буферизации (это оптимизация

обращений к системным вызовам), который ассоциирован с процессом, т.е.

буферизация происходит за счет ресурсов процесса. Мы оценивали, что хорошо,

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

медленным внешним устройством, и чем больше таких уровней, тем меньше

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

надежность системы. Например, при неожиданном для системы выключении

питания, все буфера теряют информацию. Момент обращения к обмену далек от

реального обмена, и поэтому возможны неприятные ситуации. Но, несмотря на

эти недостатки, опыт показывает, что фатальные потери информации происходят

крайне редко.

Обращаю ваше внимание, насколько UNIX экономит обращения к ВЗУ.

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

суперблока происходят не с диска, а из оперативной памяти, хотя здесь

возникает та же проблема с несанкционированным выключением питания.

Открывая файл, мы работаем с ИД. Мы выяснили, что работа с ИД

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

таблицах в оперативной памяти. Это означает, что почти нет накладных

расходов, связанных с маленькими файлами, и эти накладные расходы малы при

работе с огромными файлами. Получается так, что почти вся инфраструктура,

поддерживающая работу файловой системы, работает за счет глубокой

эшелонированной буферизации.

Атрибуты файлов

[pic]

Мы с вами говорили об организации пользователей системы; она имеет

иерархическую трехуровневую структуру.

Любой пользователь принадлежит к группе. В соответствии с иерархией

пользователей, определена иерархия защиты файлов и прав пользователей.

Определено понятие владельца файла. Изначально владельцем файла является

пользователь (а точнее, процесс пользователя), создавший этот файл. Атрибут

«владелец файла» может быть изменен командой changeown. Каждый файл имеет

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

действиям файла со стороны владельца файла. Это права на чтение, на

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

пользователя, имеются права, связанные с уровнем группы. Это права для всех

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

его самого (т.е. права владельца и его группы различны). Третья категория

защиты - все остальные. Это те права, которые имеют все пользователи

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

изменения прав доступа changemode.

Кроме атрибутов доступа, каждый файл может иметь признаки, в

частности, т.н. t-бит и s-бит, которые также устанавливаются некоторой

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

файл может находиться в очень сильно фрагментированном виде. Кроме того,

файл может быть большим, а при открытии большого файла, возникают накладные

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

файла - это длительный процесс. Чтобы оптимизировать это действие, в

системе имеется возможность пометить исполняемые файлы t-битом. После этого

происходит следующее: в том случае, если вызывается исполняемый файл,

помеченный t-битом, то при первом вызове за сеанс работы системы происходит

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

файла, сначала происходит просмотр каталога области сохранения, и в том

случае, если искомый файл там есть, то загрузка файла происходит не с ВЗУ,

а из этой области. То есть это еще один путь минимизации обращений к ВЗУ.

Обычно возможность установки t-бита - это прерогатива системного

администратора, и системный администратор сам выбирает те процессы (и

соответственно, файлы), которые надо пометить t-битом. Обычно им помечаются

те процессы, которые используются наиболее часто (если, например, идет

практикум, то t-битом имеет смысл пометить файл компилятора).

S-бит мы рассмотрим несколько поверхностно, но вернемся к нему позже.

Есть следующая проблема. Все средства системы принадлежат кому-то, т.к. все

средства, все команды (за исключением некоторых встроенных) в конечном

счете представляют из себя файлы, у которых имеется владелец. Какие-то из

этих команд могут обращаться в те или иные системные файлы. Возникает

проблема, связанная с тем, что с одной стороны, должна быть защита от

несанкционированного доступа к файлу. С другой стороны, все команды имеют

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

некоторые файлы s-битом. Владелец файла с s-битом остается неизменным, но

при запуске этого файла, владельцу процесса запустившего этот файл,

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

Предположим, есть исполняемый файл с именем file, и он работает каким-

то образом с файлом file2, в котором находится конфиденциальная информация.

Предположим, file корректирует file2, в котором находится информация обо

всех зарегистрированных пользователях и, в частности, file может менять

пароль пользователя в системе. Если я запущу file от своего имени, то могут

возникнуть две ситуации: либо я не смогу работать с file2, в котором есть

учетная информация о пользователях, потому что он закрыт для всех

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

работает s-бит. Суть его работы заключается в следующем. Владельцем

исходного файла является пользователь ROOT. Предположим, этот файл захотел

запустить пользователь с именем MASH. Если MASH запускает этот файл и нет s-

бита, то получается, что владельцем файла является ROOT, а владельцем

процесса стал MASH. В этом случае, файлы, которые недоступны пользователю

MASH, будут недоступны и его процессу, и MASH не сможет изменить свой

пароль в системе. S-бит позволяет продлить права владельца (ROOT) файла на

владельца (MASH) процесса (запущенного из этого файла), и на время сеанса

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

владельцу файла (ROOT).

Следующий вопрос: как интерпретируются права доступа к каталогам

(поскольку каталоги также являются файлами)? Разрешение на чтение из

каталога означает, что разрешен вход в каталог и открытие файлов из этого

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

уничтожать файлы в этом каталоге. Разрешение на исполнение - это

возможность поиска в данном каталоге (например, с помощью команды ls).

Файловая система с точки зрения пользователя.

Давайте рассмотрим структуру файловой системы с точки зрения

пользователя. Эта структура будет рассматриваться для обобщенной

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

В корневом каталоге есть файл с именем unix. Это тот самый файл,

который запускается программным загрузчиком, и который формирует ядро

системы.

Каталог ETC. В этом каталоге находятся стандартные файлы данных

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

функционированием системы. 1. Файл passwd. Все пользователи в

системе зарегистрированы через этот файл. Это означает, что если

пользователь может работать, то в файле passwd имеется строка, помеченная

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

символом разделителя. В частности, строка файла passwd содержит номер

группы, к которой принадлежит пользователь, иногда может содержать

закодированный пароль на вход пользователя в системе. Закодированный -

означает то, что в системе используется взаимно неоднозначная возможность

отображения последовательности символов в некоторый код, и в системе

хранится отображение этого пароля. Современные UNIX-ы хранят пароли в

отдельной защищенной базе данных (хотя файл passwd тоже присутствует),

потому что файл passwd обычно открыт на чтение, алгоритм преобразования

тоже обычно известен и есть возможность подобрать пароль.

Далее, строка содержит поле, в котором должен быть атрибут,

характеризующий фамилию, имя и отчество пользователя; поле, в котором

указывается статус пользователя; поле, в котором указан «домашний» каталог.

В этой же строке указано (или может быть указано) с каким интерпретатором

команд этот пользователь будет работать. Могут быть еще некоторые

параметры.

2. Файл rc. В этом файле в текстовом виде находится набор

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

Например, при загрузке, операционная система может запускать процесс

проверки сохранности файловой системы.

Обращаю ваше внимание, что операционная система UNIX, за исключением

нескольких случаев, содержит всю свою системную информацию в обыкновенных

текстовых файлах. Эта информация легко просматривается и легко

корректируется. В свое время, это был революционный шаг.

3. В этом же каталоге находятся команды, которые позволяют

изменять пароли пользователя (исполняемый файл passwd), позволяют

«примонтировать» к файловой системе локальные файловые системы и

отбазировать эти же локальные системы, позволяют запускать процесс

тестирования и коррекции файловой системы. Этот процесс проверяет файловую

систему по некоторому набору признаков, например, множество свободных

файлов должно при объединении с множеством занятых файлов давать все

множество файлов. И так далее.

Каталог BIN. В этом каталоге находится подавляющее число стандартных

команд системы, доступных пользователю.

Каталог MNT. Это каталог, к которому можно «примонтировать» локальные

файловые системы. До сегодняшнего дня мы считали, что файловая система

размещена на одном устройстве, но реально это не так. Имеется основная

файловая система на системном устройстве, и имеется произвольное (в

разумных пределах) количество локальных файловых систем, которые

монтируются к системе с помощью некоторой команды. Корнем локальной

файловой системы будет каталог MNT.

Каталог DER. В этом каталоге размещаются файлы, ассоциированные с

конкретными драйверами внешних устройств, например, драйверы консоли,

линейной печати и т.д. Вы помните, что файлы, ассоциированные с драйверами

внешних устройств, в ИД, который ассоциирован с их именем, имеют признак

того, что это файл-устройство, и также имеют в ИД ссылки на соответствующие

таблицы драйверов. Эти файлы не имеют содержимого.

Каталог USR. Этот каталог имеет подкаталог LIB, в котором обычно

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

предоставляемые пользователю, в т.ч. Си-компилятор с соответствующими

библиотеками поддержки.

Также, здесь имеется подкаталог BIN (/USR/BIN), в котором размещаются

администратором системы дополнительные «домотканные» команды, потому что их

размещение в каталоге /BIN считается некорректным.

Подкаталог INCLUDE. Вы помните, как выглядит строка include .

Эта строка дает команду препроцессору Си взять файл из каталога

/USR/INCLUDE. Этот каталог имеет свои подкаталоги, и для нас интересен

подкаталог SYS (/USR/INCLUDE/SYS). В нем находятся include-файлы,

ассоциированные с системными возможностями, в частности signal.h - это

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

Итак, мы закончили описание файловой системы, и можем заключить, что

файловая система UNIX иерархическая, многопользовательская. Файловая

система UNIX имеет глубокую, многоярусную буферизацию при обменах с

реальными устройствами. Файловая система UNIX является информационной

основой функционирования операционной системы. Это расширяемая файловая

система, при этом сохраняется ее целостность, т.е. при этом всегда

существует единственный путь от ее корня до любого узла (или листа).

Файловая система UNIX, с точки зрения логической организации файлов, имеет

свою понятную и прозрачную структуру. Это накладывает определенные условия

на администрацию системы, т.к. имеются проблемы координации прав доступа к

различным компонентам файловой системы, имеются проблемы размещения новой

информации в пределах файловой системы.

-----------------------

A

B

D

C

F

G

ТОФ №1

Name

I: I:

Name

J:

rw

rw

ТФ

ТИДОФ

1

1

2

Блоки

Счетчик

Индекс Наследственности

ТОФ №1

Name

I: I:

Name

J:

ТОФ №2

Name

I: I

Name

J: J:

rw

rw

ТФ

ТИДОФ

2

2

4

Блоки

Страницы: 1, 2, 3