Каков механизм создания новых процессов в UNIX?

Рисунок 1.27. Взаимодействие с устройством через файл

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

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

Помимо файлов, соответствующих внешним устройствам, в UNIX есть несколько стандартных файлов виртуальных устройств. Эти файлы могут передавать и принимать от пользовательских процессов специальные данные, например, из символьного устройства /dev/zero можно прочитать только нули, сколько бы процесс не читал данные из этого файла. Вот список наиболее распространённых виртуальных устройств:

/dev/console

устройство соответствует активной в данный момент термнальной линии (виртуальной консоли);

/dev/null

«чёрная дыра» — любая информация, записанная в этот файл, пропадает безвозвратно, обычно используется для поглощения ненужного вывода программ;

/dev/random и /dev/urandom

устройства, генерирующие соответственно случайные и псевдослучайные данные;

/dev/stdin, /dev/stdout и /dev/stderr

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

/dev/zero

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

14 Что такое контекст процесса? Из чего состоит контекст процесса в UNIX?

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

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

Идентификатор процесса (PID)

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

Идентификатор родительского процесса (PPID)

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

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

Состояние процесса.

Каждый процесс может находиться в одном из возможных состояний: инициализация, исполнение, приостановка, ожидание ввода-вывода, завершение и т.п.

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

Идентификаторы пользователя

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

Приоритет процесса

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

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

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

Другая информация, связанная с процессом.

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

15. Что такое планирование и диспетчеризация процессов? Какие алгоритмы планирования применяются в UNIX?

Это организация планирования «параллельного» выполнения нескольких процессов. Операционная система должна обладать четкими критериями для определения того, какому готовому к выполнению процессу и когда предоставить ресурс процессора.

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

Схема планирования с кольцевой очередью и приоритетами:

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

Этапы создания процесса

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

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

3. Инициализировать РСВ (блок управления процессом)

4. Добавить процесс в очередь «готовых» к выполнению.

Иерархия процессов ОС Unix

в UNIX cтрогая иерархия между процессами: дочерний и родительский всегда взаимосвязаны.

Создание процесса ОС Unix

Процессы создаются через две функции Fork() и exec()

Начинается с Fork(), он создает точный клон вызывающего процесса, так называемый «дочерний» процесс

Менеджер исполнения exec() заменяет образ процесса этого клона новой программой, которая должна быть выполнена.

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

17. Какие средства межпроцессного обмена предоставляются в UNIX?

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

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

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

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

Переменные окружения.

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

В UNIX дочерний процесс создаётся как точная копия родительского, поэтому его окружение — также точная копия родительского. Если про дочерний процесс известно, что он использует значения некоторых переменных из числа передаваемых ему с окружением, родительский может заранее указать, каким из копируемых в окружении переменных нужно изменить значение. Одна и та же программа при одинаковом использовании, но в измененном окружении — может выдавать различные результаты. Например, от переменной окружения может зависить язык интерфейса программы или формат используемых данных.

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

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

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

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

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

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

18. Какие основные сигналы существуют в операционной системе? Когда они применяются?

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

У сигнала есть только одна характеристика, несущая информацию — его номер (целое число). Иначе говоря, сигналы — это заранее определённый и пронумерованный список сообщений. Для удобства использования каждый сигнал имеет сокращённое буквенное имя. Список сигналов и их имён стандартизован и практически не отличается в различных версиях UNIX. Для отправки сигналов процессам используется специальный системный вызов kill и одноимённая ему пользовательская утилита. К основным сигналам относятся:

SIGALRM

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

SIGCHLD

Сигнал отправляется родительскому процессу в случае завершения его дочернего процесса. По умолчанию сигнал игнорируется.

SIGCONT

Сигнал продолжения исполнения программы после остановки. Обработчика по умолчанию нет.

SIGFPE

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

SIGHUP

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

SIGILL

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

SIGKILL

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

SIGPIPE

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

SIGSEGV

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

SIGSTOP

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

SIGTERM

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

SIGUSR1, SIGUSR2

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

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

Программное окружение

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

В UNIX дочерний процесс – точная копия родительского, поэтому его окружение – также точная копия родительского. Если про дочерний процесс известно, что он использует значения некоторых переменных из числа передаваемых ему с окружением, родительский может заранее указать, каким из копируемых в окружении переменных нужно изменить значение. При этом, с одной стороны, никто (кроме системы, конечно) не сможет вмешаться в процесс передачи данных, а с другой стороны, одна и та же утилита может быть использована одним и тем же способом, но в измененном окружении – и выдавать различные результаты:

user@desktop ~ $ dateПтн Ноя 5 16: 20: 16 MSK 2004user@desktop ~ $ LC_TIME=C dateFri Nov 5 16: 20: 23 MSK 2004

В последнем примере пользователь присвоил некоторое значение переменной окружения в командной строке перед именем команды. Командный интерпретатор, увидев «=» внутри первого слова командной строки, приходит к выводу, что это – операция присваивания, а не имя команды, и запоминает, как надо изменить окружение команды, которая последует далее. Переменная окружения LC_TIME предписывает использовать определенный язык при выводе даты и времени, а значение " C" соответствует стандартному системному языку (чаще всего – английскому).

Для получения значения переменной окружения необходимо воспользоваться символом «$»:

user@desktop ~ $ echo $PWD/home/user

Командная оболочка

Основная среда взаимодействия с UNIX – командная строка. Суть её в том, что каждая строка, передаваемая пользователем системе, – это команда, которую та должна выполнить. Пока не нажата клавиша Enter, строку можно редактировать, затем она отсылается системе.

Команды интерпретируются и выполняются специальной программой – командной оболочкой (или «shell», по-английски). Через командную оболочку производится управление пользовательскими процессами – для этого используются средства межпроцессного обмена, описанные ранее (см. «Межпроцессное взаимодействие»).

Командная оболочка непосредственно связана с терминалом, через который осуществляется передача управляющих последовательностей и текста. На рисунке Рис.2.1, «Интерфейс командной строки» представлена общая схема взаимодействия пользователя с системой при использовании командной строки.

Рис.2.1. Интерфейс командной строки

Процесс выполнения команды:

Командная оболочка – это обычный процесс в операционной системе UNIX. Когда пользователь вводит команду (например, по нажатию Enter ), командная оболочка выполняет следующие действия:

анализ команды: выделение имени, параметров и аргументов;

если это встроенная команда, для неё вызывается функция-обработчик;

если это внешняя команда:

производится поиск программы с соответствующим именем;

создаётся дочерний процесс оболочки (системный вызов fork);

в дочернем процессе запускается необходимая команда с расшифрованными параметрами и аргументами (системный вызов exec);

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

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

Рис.2.3. Запуск команды оболочкой

24. Какие существуют средства объединения команд? Чем они различаются?

Способы объединения команд

Презентация 3-06: способы объединения команд

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

Последовательное выполнение.

Команды выполняются одна за другой, не зависимо от результата их исполнения. В качестве разделителя выступает символ точки с запятой («; »).

В качестве примера можно рассмотреть составную команду du -sh; date, которая выводит на экран содержимое домашней директории, а затем текущие дату и время.

Условное выполнение (И)

Проверяется код завершения первой программы, если он равен 0, производится выполнение второй программы, и так далее. Таким образом, последняя команда выполнится только при успешном завершении всех предыдущих. В качестве разделителя выступают два амперсанда («& & »).

В качестве примера можно рассмотреть составную команду test -r /tmp/txt & & cp /tmp/txt., которая проверяет возможность чтения файла /tmp/txt и в случае успеха, копирует этот файл в локальную директорию.

Условное выполнение (ИЛИ)

Проверяется код завершения первой программы, если он не равен 0, производится выполнение второй программы, и так далее. Последняя команда будет запущена только если ни одна из предыдущих не закончилась успешно. В качестве разделителя выступают две вертикальный черты («||»).

В качестве примера можно рассмотреть составную команду test -d /tmp/dir || mkdir /tmp/dir, которая проверяет существование директории /tmp/dir и если её нет, создаёт её.

Конвейер

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

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

В качестве разделителя используется символ вертикальный черты («|»).

Рассмотрим пример команды cat file.txt | uniq | sort, которая читает содержимое файла file.txt, удаляет из него повторяющиеся строки и сортирует оставшиеся строки по алфавиту. Результат выводится на экран.

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

Что входит в справочную систему UNIX?

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

Справочные руководства делятся на разделы – в зависимости от типа описываемых объектов. Если один и тот же термин описывается в нескольких разделах, необходимо явно указать, какой из них использовать, например, man 3 printf для 3-го раздела руководств.

Всего существует 8 разделов руководств:

1. пользовательские утилиты и прочие инструменты

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

3. библиотечные функции

4. внешние устройства (и их представление в системе)

5. форматы и таблицы (типы файлов, протоколы и прочее)

6. игры и всевозможные «ненужные» утилиты

7. «остальное», т. е. То, что не подходит под другие разделы

8. команды и инструменты системного администратора

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

Другой источник информации о UNIX (а точнее, в UNIX-подобных системах, базирующихся на программном обеспечении от GNU) и составляющих ее программах – справочная подсистема info. Страница руководства, несмотря на обилие ссылок различного типа, остается «линейным» текстом, структурированным только логически. Документ info структурирован прежде всего топологически – это настоящий гипертекст, в котором множество небольших страниц объединены в дерево. В каждом разделе документа info всегда есть оглавление, из которого можно перейти сразу к нужному подразделу, откуда всегда можно вернуться обратно. Кроме того, info-документ можно читать и как непрерывный текст, поэтому в каждом подразделе есть ссылки на предыдущий и последующий подразделы.

Еще есть документация поставляемая с программой (обычно помещается в каталог /usr/share/doc/имя_объекта)

Чем отличаются номинальный и действительный субъект? Как они соотносятся с объектом безопасности? Что представляют собой субъект и объект безопасности в UNIX?

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

Действительным субъектом системы назовем любую сущность, способную выполнять действия над объектами (имеющую к ним доступ). Действительному субъекту системы соответствует некоторая абстракция, на основании которой принимается решение о предоставлении доступа к объекту или об отказе в доступе. Такая абстракция называется номинальным субъектом. Например, студент МГТУ – действительный субъект, его пропуск в МГТУ – номинальный. Другим примером может служить злоумышленник, прокравшийся в секретную лабораторию с украденной картой доступа – он является действительным субъектом, а карта – номинальным.

Что такое политика безопасности? Какие требования выдвигаются по отношению к ней?

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

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

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

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

Политика безопасности включает в себя технические, организационные и правовые аспекты.

28. Какие существуют наиболее распространённые схемы доступа? В чём заключаются основные отличия между ними? Какая схема доступа используется в UNIX?

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

1) Мандатная модель доступа. Объектам и субъектам системы ставится в соответствие метка безопасности или мандат (например, гриф секретности). При этом метка безопасности субъекта описывает его благонадёжность, а метка безопасность объекта — степень закрытости информации. Доступ к объекту разрешён только субъектам с соответствующей или более сильной меткой.

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

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

Недостатками можно считать огромный размер таблицы и сложность администрирования в случае большого числа объектов и субъектов в системе.

3) Произвольное управление доступом. Каждому объекту сопоставляется один субъект — владелец объекта. Владелец может по своему усмотрению давать другим субъектам или отнимать у них права на доступ к объекту. Если объект имеет несколько хозяев, они могут быть объединены общим субъектом — группой. Такая схема позволяет значительно сократить размер таблицы прав субъектов по отношению к объектам. Эта схема также называется субъект-субъектная модель.

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

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

29. Какие существуют права доступа в UNIX? Какие из них являются специфичными для простых файлов, а какие для директорий?

На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r), запись (write, w) и использование (execution, x). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи – возможность ее изменять. При каждом файле имеется список того, что с ним может делать владелец, член группы владельцев и кто угодно.

Флаг использования трактуется по-разному в зависимости от типа файла. В случае простого файла он задаёт возможность исполнения файла, т.е. запуска программы, содержащейся в этом файле. Для директории – это возможность доступа к файлам в этой директории (точнее говоря, к атрибутам этих файлов – имени, правам доступа и т.п..).

30. Что такое подмена идентификатора процесса? Как такое право устанавливается и в каких случаях применяется?

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

Подмена идентификатора в том случае, если процесс запустит вместо себя при помощи системного вызова exec() программу из файла, в правах доступа которого установлен бит подмены идентификатора пользователя (SUID-бит, обозначается s в символьной записи прав доступа). Запущенный из этого файла процесс получит исполнительный идентификатор владельца (EUID) файла вместо идентификатора владельца процесса-родителя (см. Рисунок 2.19, «Подмена идентификатора процесса»), благодаря чему UID процесса сохраняет информацию о том, кто на самом деле запустил программу.

В современных UNIX-системах предусмотрен и ещё один дополнительный атрибут — SetGID, бит подмены идентификатора группы. Этот механизм работает совершенно аналогично подмене идентификатора пользователя, с тем отличием, что процесс, запущенный из файла с атрибутом SetGID, получает идентификатор группы-владельца файла, UID же его остается неизменным. Использование SetGID позволяет весьма гибким образом контролировать ситуацию повышения прав доступа процесса.

Особое значение имеют атрибуты подмены идентификатора (SetUID и SetGID), установленные на каталогах (о других правах доступа для каталогов сказано в разделе «Разделяемые каталоги») — для каталогов тоже используются права на исполнение, хотя и имеют другой смысл, чем у исполняемых файлов. Атрибут SetGID, установленный на каталоге, указывает, что файлы и подкаталоги, создаваемые внутри этого подкаталога любыми процессами, будут получать тот же идентификатор группы, что и сам каталог. Причем подкаталоги будут также наследовать атрибут SetGID. Такой механизм используется для организации обзих каталогов, файлы в которых должны быть доступны на равных условиях группе пользователей. Атрибут SetUID, установленный на каталоге, просто игнорируется.

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

31. Из каких этапов состоит процесс аутентификации пользователя в UNIX?

В UNIX сеанс работы пользователя начинается с его аутентификации и заканчивается его выходом из системы. При входе в систему выполняется следующая последовательность действий (см. Рисунок 2.20, «Регистрация пользователя в системе»):

12 3 4 5 Следующая ⇒