Учебное пособие 1461

эквивалентна монтированию файловой системы на /dev/hda3 в примере fstab, рассмотренном ранее. В данном случае команде mount передается три параметра ext2, /dev/hda3 и /usr - которые содержат соответственно тип файловой системы, файл устройства, на котором располагается файловая система и точка монтирования. Как правило, обычно бывает достаточно указать два параметра: файл устройства и точка монтирования.

Обычно пользователю не приходится монтировать и размонтировать файловые системы вручную. Команда mount - av в /etc/rc позаботится о монтировании файловых систем во время загрузки. Файловые системы автоматически размонтируются командами shutdown или halt перед выключением системы.

В файле /etc/mtab хранится информация о том, какие файловые системы сейчас смонтированы и с какими параметрами монтирования это было сделано. Данные о смонтированных файловых системах содержатся также в файле /proc/mounts (и там они точнее, поскольку отображают соответствующую внутреннюю таблицу ядра), но параметров, с которыми эти системы были смонтированы, в нем нет, поскольку они в ядре не хранятся (а те из них, которые интерпретируются программой mount, вообще не доходят до ядра), поэтому /etc/mtab также находит применение.

Как уже было сказано, монтирование файловых систем выполняется командой mount, а их размонтирование - командой unmount (в некоторых системах umount). Исключение составляет корневая файловая система, которая обслуживается отдельно и до всех остальных систем. Действительно, только при ее наличии становятся доступными и сама команда mount, и каталог /dev, где находятся файлы устройств, и подкаталоги для монтирования. Чтобы файловые системы можно было монтировать при запуске ОС и

31

размонтировать при ее остановке, используются два файла, которые традиционно размещаются в подкаталоге /etc: /etc/fstab и /etc/mtab. Файл /etc/fstab содержит список файловых систем, которые могут быть смонтированы. Конечно, необходимые параметры всегда можно указать при вызове команды mount, но гораздо удобнее, когда они извлекаются из файла.

Каждой точке монтирования в нем соответствует одна строка, состоящая из шести полей: название устройства, на котором расположена файловая система, точка монтирования, тип файловой системы, параметры монтирования, "уровень дампа" и порядковый номер файловой системы для программы fsck.

Примеры монтирования и размонтирования: $ mount /dev/hda2 /home

$ umount /home

1.15. Права доступа к файлам и каталогам в ОС Unix

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

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

32

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

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

Выполним команду ls -l, но зададим ей в качестве дополнительного параметра имя конкретного файла:

user@localhost:~$ ls -l file

-rwxr-xr-x 1 user user 6 2009-09-17 13:49 file

Вы видите, что в данном случае владельцем файла является пользователь user и группа user. Но нас сейчас в выводе этой команды больше интересует первое поле, определяющее тип файла и права доступа к файлу. Это поле в приведенном примере представлено цепочкой символов -rwxr- xr-x. Эти символы можно условно разделить на 4 группы.

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

- — обычный файл; d — каталог;

b — файл блочного устройства;

c — файл символьного устройства; s — доменное гнездо (socket);

p — именованный канал (pipe);

l — символическая ссылка (link).

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

33

(user) имеет право читать файл (r), производить запись в этот файл (w), и запускать файл на выполнение (x). Замена любого из этих символов прочерком будет означать, что пользователь лишается соответствующего права. В том же примере мы видим, что все остальные пользователи (включая и тех, которые вошли в группу user) лишены права записи в этот файл, т. е. не могут файл редактировать и вообще как-то изменять.

Вообще говоря, права доступа и информация о типе файла в UNIX-системах хранятся в индексных дескрипторах в отдельной структуре, состоящей из двух байтов, т. е. из 16 бит (это естественно, ведь компьютер оперирует битами, а не символами r, w, x). Четыре бита из этих 16-ти отведены для кодированной записи о типе файла. Следующие три бита задают особые свойства исполняемых файлов, о которых мы скажем чуть позже. И, наконец, оставшиеся 9 бит определяют права доступа к файлу. Эти 9 бит разделяются на 3 группы по три бита. Первые три бита задают права пользователя, следующие три бита — права группы, последние 3 бита определяют права всех остальных пользователей (т. е. всех пользователей, за исключением владельца файла и группы файла).

При этом, если соответствующий бит имеет значение 1, то право предоставляется, а если он равен 0, то право не предоставляется. В символьной форме записи прав единица заменяется соответствующим символом (r, w или x), а 0 представляется прочерком.

Право на чтение (r) файла означает, что пользователь может просматривать содержимое файла с помощью различных команд просмотра, например, командой more или с помощью любого текстового редактора. Но, подредактировав содержимое файла в текстовом редакторе, вы не сможете сохранить изменения в файле на диске, если не имеете права на запись (w) в этот файл. Право на выполнение (x) означает,

34

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

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

Для изменения прав доступа к файлу используется команда chmod. Один из вариантов задания команды chmod (он используется чаще) основан на цифровом представлении прав. Для этого мы кодируем символ r цифрой 4, символ w — цифрой 2, а символ x — цифрой 1. Для того, чтобы предоставить пользователям какой-то набор прав, надо сложить соответствующие цифры. Например, если надо дать все права владельцу (4+2+1=7), право на чтение и запись — группе (4+2=6), и не давать никаких прав остальным, то следует дать такую команду:

user@localhost:~$ chmod 760 file.txt

35

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

2. УПРАВЛЕНИЕ ПРОЦЕССАМИ

2.1. Управление процессами операционных систем

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

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

–операционная система прекращает его деятельность;

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

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

36

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

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

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

Системы, управляющие процессами, должны иметь возможность выполнять определенные операции над процессами:

–создание процесса;

–уничтожение процесса;

–возобновление процесса;

–изменение приоритета процесса;

–блокирование процесса;

–пробуждение процесса;

–запуск процесса.

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

–присвоение имени процессу;

–включение этого имени в список имен, известных системе;

–определение начального приоритета процесса;

–формирование блока управления процессом;

37

– выделение процессу начальных ресурсов.

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

Process Control Block (Блок управления процессом)

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

–состояние, в котором находится процесс;

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

–содержимое регистров процессора;

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

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

38

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

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

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

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

2.2. Реализация взаимоисключений процессов

2.2.1. Понятие параллельных и асинхронных процессов

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

39

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

1.Процесс, который обращается к разделяемым данным находится в своем критическом участке.

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

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

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

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

2.2.2. Алгоритм Деккера

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

Алгоритм Деккера. Procedure процесс1;

Begin

While истина do Begin

П1хочетвойти:=истина;

40