Файловая подсистема

Размещено на http://www.allbest.ru/

ЛЕКЦИЯ №3

Файловая подсистема

Содержание занятия

1. Общий взгляд на архитектуру UNIX

1.1 Двухуровневая модель системы UNIX

1.2 Ядро системы

1.3 Работа в операционной системе UNIX

2. Файлы и файловая система

2.1 Типы файлов

2.1.1 Обычный файл (regular file)

2.1.2 Каталог

2.1.3 Специальный файл устройства (special device file)

2.1.4 FIFO или именованный канал (named pipe)

2.1.5 Связь (link)

2.2 Сокеты

2.3 Структура файловой системы UNIX

2.4 Приведем краткое описание основных каталогов

2.4.1 Корневой каталог

2.4.2 /bin

2.4.3 /dev

2.4.4 /etc

2.4.5 /lib

2.4.6 /lost+found

2.4.7 /mnt

2.4.8 /usr

2.4.9 /var

2.4.10 /tmp

2.5 Владельцы файлов

3. Права доступа к файлу

1. Общий взгляд на архитектуру UNIX

1.1 Двухуровневая модель системы UNIX

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

Рис. 1. - Двухуровневая модель системы UNIX:

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

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

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

1.2 Ядро системы

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

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

В приведенном примере программа открывает файл, считывает из него данные и закрывает этот файл. При этом операции открытия (open), чтения (read) и закрытия (close) файла выполняются ядром по запросу задачи, а функции ореn(2), read(2) и close(2) являются системными вызовами.

Ядро состоит из трех основных подсистем:

- Файловая подсистема;

- Подсистема управления процессами и памятью;

- Подсистема ввода/вывода;

- Файловая подсистема.

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

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

Подсистема управления процессами: Запущенная на выполнение программа порождает в системе один или более процессов (или задач).

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

- Создание и удаление процессов;

- Распределение системных ресурсов (памяти, вычислительных ресурсов) между процессами;

- Синхронизацию процессов;

- Между процессное взаимодействие.

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

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

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

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

Подсистема ввода/вывода: Подсистема ввода/вывода выполняет запросы файловой подсистемы и подсистемы управления процессами для доступа к периферийным устройствам (дискам, магнитным лентам, терминалам и т. д.).

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

1.3 Работа в операционной системе UNIX

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

С точки зрения пользователя в операционной системе UNIX существуют два типа объектов: файлы и процессы. Все данные хранятся в виде файлов, доступ к периферийным устройствам осуществляется посредством чтения/записи в специальные файлы. Когда вы запускаете программу, ядро загружает соответствующий исполняемый файл, создает образ процесса и передает ему управление. Более того, во время выполнения процесс может считывать или записывать данные в файл. С другой стороны, вся функциональность операционной системы определяется выполнением соответствующих процессов. Работа системы печати или обеспечения удаленного доступа зависит от того, выполняются ли те или иные процессы в системе 1.

В этой главе мы:

- познакомимся с пользовательской средой операционной системы UNIX;

- попробуем взглянуть на UNIX глазами обычного пользователя и администратора системы;

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

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

Мы также:

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

- изучим сеанс работы в операционной системе и подробно остановимся на командном интерпретаторе shell - базовой рабочей среде пользователя;

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

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

2. Файлы и файловая система

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

Как и во многих современных операционных системах, в UNIX файлы организованы в виде древовидной структуры (дерева), называемой файловой системой (file system). Каждый файл имеет имя, определяющее его расположение в дереве файловой системы. Корнем этого дерева является корневой каталог (root directory), имеющий имя "/". Имена всех остальных файлов содержат путь - список каталогов (ветвей), которые необходимо пройти, чтобы достичь файла. В UNIX все доступное пользователям файловое пространство объединено в единое дерево каталогов, корнем которого является каталог "/". Таким образом, полное имя любого файла начинается с "/" и не содержит идентификатора устройства (дискового накопителя, CD-ROM или удаленного компьютера в сети), на котором он фактически хранится.

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

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

2.1 Типы файлов

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

- Обычный файл (regular file);

- Каталог (directory);

- Специальный файл устройства (special device file);

- FIFO или именованный канал (named pipe);

- Связь (link);

- Сокет.

2.1.1 Обычный файл (regular file)

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

2.1.2 Каталог

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

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

Рис. 2. - Структура каталога:

2.1.3 Специальный файл устройства (special device file)

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

2.1.4 FIFO или именованный канал (named pipe)

FIFO или именованный канал - это файл, используемый для связи между процессами. FIFO впервые появились в System V UNIX, но большинство современных систем поддерживают этот механизм. Более подробно мы рассмотрим этот тип файлов при обсуждении системы межпроцессного взаимодействия.

2.1.5 Связь (link)

Связь. Как уже говорилось, каталог содержит имена файлов и указатели на их метаданные. В то же время сами метаданные не содержат ни имени файла, ни указателя на это имя. Такая архитектура позволяет одному файлу иметь несколько имен в файловой системе. Имена жестко связаны с метаданными и, соответственно, с данными файла, в то время как сам файл существует независимо от того, как его называют в файловой системе 2. Такая связь имени файла с его данными называется жесткой связью (hard link). Например, с помощью команды 1п(1) мы можем создать еще одно имя (second) файла, на который указывает имя first (рис. 3).

Жесткие связи абсолютно равноправны. В списках файлов каталогов, которые можно получить с помощью команды ls(l), файлы first и second будут отличаться только именем. Все остальные атрибуты файла будут абсолютно одинаковыми. С точки зрения пользователя - это два разных файла. Изменения, внесенные в любой из этих файлов, затронут и другой, поскольку оба они ссылаются на одни и те же данные файла. Вы можете переместить один из файлов в другой каталог - все равно эти имена будут связаны жесткой связью с данными файла. Легко проверить, что удаление одного из файлов (first или second) не приведет к удалению самого файла, т. е., его метаданных и данных (если это не специальный файл устройства).

Рис. 3. - Структура файловой системы после выполнения команды ln(1). Жесткая связь имен с данными файла:

По определению жесткие связи указывают на один и тот же индексный дескриптор inode.

Поэтому проверить, имеют ли два имени файла жесткую связь, можно, вызвав команду ls(l) с ключом:

12567 first;

12567 second.

Информацию о наличии у файла нескольких имен, связанных с ним жесткими связями, можно получить, просмотрев подробный листинг файлов с помощью команды "Is-/:$Is-1/home/sergey", или "-rw-r-г-2andrei/staff7245Jan/17/8:05second".

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

Проиллюстрируем эти рассуждения на примере. Команда ln(1) с ключом s позволяет создать символическую связь: "$pwd/home/andrei$In-з/first/home/sergey/symfirst/$/cd/home/sergey".

Как видно из вывода команды ls(l), файл symfirst (символическая связь) существенно отличается от файла second (жесткая связь). Во-первых, фактическое содержимое файла symfirst отнюдь не то же, что и у файла first или second, об этом говорит размер файла - 15 байт. На самом деле в этом файле хранится не что иное как имя файла, на которую символическая связь ссылается - "../andrei/first" - ровно 15 байт. Во-вторых, файл symfirst не содержит никаких ограничений на доступ (2-10 символы в первой колонке).

Символическая связь является особым типом файла (об этом свидетельствует символ "Г" в первой позиции вывода ls(l)), и операционная система работает с таким файлом не так, как с обычным. Например, при выводе на экран содержимого файла symfirst появятся данные файла "/home/andrei/first".

Информацию о наличии у файла нескольких имен, связанных с ним жесткими связями, можно получить, просмотрев подробный листинг файлов с помощью команды "Is-/:$Is-1/home/sergey".

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

Проиллюстрируем эти рассуждения на примере. Команда ln(1) с ключом s позволяет создать символическую связь: "$pwd/home/andrei".

Рис. 4. - Символическая связь:

Как видно из вывода команды ls(l), файл symfirst (символическая связь) существенно отличается от файла second (жесткая связь).

Во-первых, фактическое содержимое файла symfirst отнюдь не то же, что и у файла first или second. Об этом говорит размер файла - 15 байт. На самом деле в этом файле хранится не что иное как имя файла, на которую символическая связь ссылается "-../andrei/first" - ровно 15 байт.

Во-вторых, файл symfirst не содержит никаких ограничений на доступ (2-10 символы в первой колонке).

Символическая связь является особым типом файла (об этом свидетельствует символ "Г" в первой позиции вывода ls(l)), и операционная система работает с таким файлом не так, как с обычным. Например, при выводе на экран содержимого файла symfirst появятся данные файла "/home/andrei/first".

2.2 Сокеты

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

Мы подробнее познакомимся с сокетами в разделе "Между процессное взаимодействие в BSD UNIX".

2.3 Структура файловой системы UNIX

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

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

Нарушение этой структуры может привести к неработоспособности системы или отдельных ее компонентов.

Рис. 5. - Типичная файловая система UNIX:

2.4 Приведем краткое описание основных каталогов

2.4.1 Корневой каталог

Корневой каталог "/" является основой любой файловой системы UNIX.

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

2.4.2 /bin

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

2.4.3 /dev

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

Например, каталог /dev/dsk содержит специальные файлы устройств для доступа к гибким и жестким дискам системы.

2.4.4 /etc

В этом каталоге находятся системные конфигурационные файлы и многие утилиты администрирования. Среди наиболее важных файлов - скрипты инициализации системы. Эти скрипты хранятся в каталогах "/etc/rcO.d", "/etc/rcl.d" или "/etc/rc2.d" и т. д., соответствующих уровням выполнения системы (run level), и управляются скриптами "/etc/rcO", "/etc/rcl", "/etc/rc2" и т. д.

Во многих версиях BSD UNIX указанные каталоги отсутствуют, и загрузка системы управляется скриптами "/etc/reboot", или "/etc/re" или "/etc/rc.local".

В UNIX ветви System V здесь находится подкаталог default, где хранятся параметры по умолчанию многих команд. В UNIX System V большинство исполняемых файлов перемещены в каталог "/sbin" или "/usr/sbin".

2.4.5 /lib

В каталоге /lib находятся библиотечные файлы языка С и других языков программирования. Стандартные названия библиотечных файлов имеют вид libx.a (или libx.so), где х - это один или более символов, определяющих содержимое библиотеки. Например, стандартная библиотека "С" называется libc.a, библиотека системы "X Window System" имеет имя libXll.a. Часть библиотечных файлов также находится в каталоге /usr/lib.

2.4.6 /lost+found

Каталог "потерянных" файлов. Ошибки целостности файловой системы, возникающие при неправильном останове UNIX или аппаратных сбоях, могут привести к появлению т. н. "безымянных" файлов - структура и содержимое файла являются правильными, однако для него отсутствует имя в каком-либо из каталогов. Программы проверки и восстановления файловой системы помещают такие файлы в каталог "/lost+found" под системными числовыми именами.

2.4.7 /mnt

Стандартный каталог для временного связывания (монтирования) физических файловых систем к корневой для получения единого дерева логической файловой системы. Обычно содержимое каталога /mnt пусто, поскольку при монтировании он перекрывается связанной файловой системой. Общеупотребительный каталог для размещения домашних каталогов пользователей. Например, имя домашнего каталога пользователя andrei будет, скорее всего, называться "/home/andrei" или "/u/andrei".

В более ранних версиях UNIX домашние каталоги пользователей размещались в каталоге /usr.

2.4.8 /usr

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

Вид (/usr/spool), исполняемые файлы утилит UNIX (/usr/bin), дополнительные программы, используемые на данном компьютере (/usr/local), файлы заголовков (/usr/include), электронные справочники (/usr/man) и т. д.

2.4.9 /var

В UNIX System V этот каталог является заменителем каталога /usr/spool, используемого для хранения временных файлов различных сервисных подсистем - системы печати, электронной почты и т. д.

2.4.10 /tmp

Каталог хранения временных файлов, необходимых для работы различных подсистем UNIX. Обычно этот каталог открыт на запись для всех пользователей системы.

2.5 Владельцы файлов

Файлы в UNIX имеют двух владельцев: пользователя (user owner) и группу (group owner). Важной особенностью является то, что владелец-пользователь может не являться членом группы, владеющей файлом. Группой называется определенный список пользователей системы. Пользователь системы может быть членом нескольких групп, одна из которых является первичной (primary), остальные - дополнительными (supplementary).

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

Для определения владельцев файла достаточно посмотреть подробный листинг команды Is-l.

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

Рис. 6:

Владельцем-пользователем вновь созданного файла является пользователь, который создал файл. Порядок назначения владельца-группы зависит от конкретной версии UNIX. Например, в SCO UNIX владельцем-группой является первичная группа пользователя, создавшего файл, а в Digital UNIX владелец-группа наследуется от владельца группы - каталога, в котором создается файл 4.

Для изменения владельца файла используется команда chown(l). В качестве параметров команда принимает имя владельца-пользователя и список файлов, для которых требуется изменить данный атрибут. Например, следующая команда установит пользователя sergey владельцем файлов client.c и server.c: "$chown/sergey/client.с/server.с".

Изменение владельца-группы производится командой "chgrp(l)". Как и "chown(l)", в качестве параметров команда принимает имя владельца-группы и список файлов, для которых требуется изменить данный атрибут. Например, для установки группы staff в качестве владельца всех файлов текущего каталога, необходимо задать следующую команду: "$/chgrp/staff/*".

На самом деле файл создает не пользователь, а процесс, запущенный пользователем. Процесс имеет атрибуты, связанные с пользователем и группой, которые и назначаются файлу при его создании. Более точное описание передачи "владения" имеет идентификатор владельца-пользователя файла (UID) устанавливается равным EUID процесса, создающего файл (т. е. вызвавшего функцию ореn(2) или creat(2)):

1. Идентификатор владельца-группы файла (group ID) устанавливается равным:

а) EGID процесса (для версии System V);

б) GID каталога, в котором файл создается (для версии BSD).

Большинство систем, использующих наследование System V, позволяют также устанавливать наследование группового владельца в стиле BSD. Это достигается установкой флага SGID на каталог. Владение файлом определяет тот набор операций, который пользователь может совершить с файлом. Часть из них, такие как изменение прав доступа или владельца файла (табл. 1), может осуществлять только владелец (или суперпользователь), другие операции, такие как чтение, запись и запуск на выполнение (для исполняемых файлов) дополнительно контролируются правами доступа.

Таблица 1. - Операции изменения владельцев файла:

Операция	Команда	Имеет право выполнять
		в системе BSD 4.x	в системе SVR4
Изменение владельца-пользователя Изменение владельца-группы	chown(1) chgrp(1)	суперпользователь суперпользователь	владелец файла владелец файла только для группы, к которой сам принадлежит (в соответствии с POSIX)

3. Права доступа к файлу

В операционной системе UNIX существуют три базовых класса доступа к файлу, в каждом из которых установлены соответствующие права доступа. UNIX поддерживает три типа прав доступа для каждого класса: на чтение (read, обозначается символом г), на запись (write, обозначается символом w) и на выполнение (execute, обозначается символом х).

С помощью команды Is -l можно получить список прав доступа к файлу:

Рис. 7:

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

Наличие права доступа обозначается соответствующим символом, а отсутствие - символом "-". Рассмотрим, например, права доступа к файлу "a.Ollt".

Права доступа могут быть изменены только владельцем файла или суперпользователем (superuser) - администратором системы.

Для этого используется команда chmod(l). Ниже приведен общий формат этой команды.

В качестве аргументов команда принимает указание классов доступа ("и" - владелец-пользователь, "g" - владелец-группа, "о" - остальные пользователи, "а" - все классы пользователей), права доступа ("г" - чтение, V - запись и Y - выполнение) и операцию, которую необходимо произвести ("+" - добавить, "-" - удалить и "=" - присвоить) для файлов "/ilelfile2" и т. д. Например, команда "$/chmod/g-wx/ownf/ile" лишит членов группы-владельца файла ownfile права на запись и выполнение этого файла. В одной команде можно задавать различные права для нескольких классов доступа, разделив их запятыми. Приведем еще пример: "$/chmod/a+w/text".

Последний пример демонстрирует достаточно сложную установку прав доступа. Вы можете установить сразу все девять прав доступа, используя числовую форму команды chmod(l): "$/chmod/754/*".

Число определяется следующим образом: нужно представить права доступа в двоичном виде (0 - отсутствие соответствующего права, 1 - его наличие) и каждую триаду, соответствующую классу доступа, в свою очередь преобразовать в десятичное число.

Таблица 2:

Владелец	Группа	Остальные
Г W X	Г - х	Г -
111	10 1	10 0
7	5	4

Таким образом, приведенный пример эквивалентен следующей символьной форме "chmod(l)": "$/chmod/u=rwx/g=rx/o=r/*".

Значение прав доступа различно для разных типов файлов. Для файлов операции, которые можно производить, следуют из самих названий прав доступа. Например, чтобы просмотреть содержимое файла командой cat(l), пользователь должен иметь право на чтение (г). Редактирование файла, т. е. его изменение, предусматривает наличие права на запись (w). Наконец, для того чтобы запустить некоторую программу на выполнение, вы должны иметь соответствующее право (х). Исполняемый файл может быть как скомпилированной программой, так и скриптом командного интерпретатора shell. В последнем случае вам также понадобится право на чтение, поскольку при выполнении скрипта командный интерпретатор должен иметь возможность считывать команды из файла. Все сказанное, за исключением, пожалуй, права на выполнение, имеющего смысл лишь для обычных файлов и каталогов, справедливо и для других типов файлов: специальных файлов устройств, именованных каналов, и сокетов. Например, чтобы иметь возможность распечатать документ, вы должны иметь право на запись в специальный файл устройства, связанный с принтером5. Для каталогов эти права имеют другой смысл, а для символических связей они вообще не используются, поскольку контролируются целевым файлом.

Права доступа для каталогов не столь очевидны. Это в первую очередь связано с тем, что система трактует операции чтения и записи для каталогов отлично от остальных файлов. Право чтения каталога позволяет вам получить имена (и только имена) файлов, находящихся в данном каталоге. Чтобы получить дополнительную информацию о файлах каталога (например, подробный листинг команды Is-Г), системе придется "заглянуть" в метаданные файлов, что требует права на выполнения для каталога. Право на выполнения также потребуется для каталога, в который вы захотите перейти (т. е., сделать его текущим) с помощью команды cd (]). Это же право нужно иметь для доступа ко всем каталогам на пути к указанному. Например, если вы установите право на выполнения для всех пользователей в одном из своих подкаталогов, он все равно останется недоступным, пока ваш домашний каталог не будет иметь такого же права.

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

Рис. 8:

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

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

Таблица 3. - Примеры прав доступа:

Команда	Смысл действия	Минимальные права доступа
		для обычного файла	для каталога, содержащего файл
cd /u/andrei	Перейти в каталог /u/andrei	-	X
Is /u/andrei/*. с	Вывести все файлы с суффиксом.с этого каталога		Г
Is -s /u/andrei/*.с	Вывести дополнительную информацию об этих файлах (размер)		Гх
cat report.txt	Вывести на экран содержимое файла report.txt	Г	X
cat >> report.txt	Добавить данные в файл report.txt	W	X
runme.sh	Выполнить программу runme	X	X
Runme	Выполнить скрипт командного интерпретатора runme.sh	Гх	X
rm runme	Удалить файл runme в текущем каталоге	-	XW

Итак, для выполнения операции над файлом имеют значение класс доступа, к которому вы принадлежите, и права доступа, установленные для этого класса. Поскольку для каждого класса устанавливаются отдельные права доступа, всего определено 9 прав доступа, по 3 на каждый класс.

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

1. Если операция запрашивается суперпользователем, доступ разрешается. Никакие дополнительные проверки не производятся. Это позволяет администратору иметь неограниченный доступ ко всей файловой системе.

2. Если операция запрашивается владельцем файла, то:

а) если требуемое право доступа определено (например, при операции чтения файла установлено право на чтение для владельца-пользователя данного файла), доступ разрешается;

б) в противном случае доступ запрещается.

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

а) если требуемое право доступа определено, доступ разрешается;

б) в противном случае доступ запрещается.

4. Если требуемое право доступа для прочих пользователей (other) установлено, доступ разрешается, в противном случае доступ запрещается.

Система проводит проверки в указанной последовательности. Например, если пользователь является владельцем файла, то доступ определяется исключительно из прав владельца-пользователя, права владельца-группы не проверяются, даже если пользователь является членом владельца-группы. Чтобы проиллюстрировать это, рассмотрим следующее: "rw-r-2/andy/group/65/Dec/22/19:13/filel".

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

Дополнительные атрибуты файла.

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

Дополнительные атрибуты также устанавливаются утилитой chmod(l), но вместо кодов "г", W или Y используются коды. Например, для установки атрибута SGID для файла filel необходимо выполнить команду "$/chmod/g+s/filel". В табл. 4 приведены дополнительные атрибуты для файлов, и показано, как они интерпретируются операционной системой.

Таблица 4. - Дополнительные атрибуты для обычных файлов:

Код	Название	Значение
t	Sticky bit	Сохранить образ выполняемого файла в памяти после завершения выполнения
S	Set UID, SUID	Установить UID процесса при выполнении
S	SetGID, SGID	Установить GID процесса при выполнении
1	Блокирование	Установить обязательное блокирование файла

Установка атрибута Sticky bit (действительное название - save text mode) редко используется в современных версиях UNIX для файлов. В ранних версиях этот атрибут применялся с целью уменьшить время загрузки наиболее часто запускаемых программ (например, редактора или командного интерпретатора). После завершения выполнения задачи ее образ (т. е. код и данные) оставались в памяти, поэтому последующие запуски этой программы занимали значительно меньше времени.

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

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

В качестве примера использования этого свойства рассмотрим утилиту "passwd(l)", позволяющую пользователю изменить свой пароль. Очевидно, что изменение пароля должно привести к изменению содержимого определенных системных файлов (файла пароля "/etc/passwd" или "/etc/shadow", или базы данных пользователей, если используется дополнительная защита системы). Понятно, что предоставление права на запись в эти файлы всем пользователям системы является отнюдь не лучшим решением. Установка SUID для программы passwd(l) позволяет изящно разрешить это противоречие. Следует оговориться, что если программа в процессе выполнения запускает другие задачи, то они будут наследовать ее права доступа. Поэтому устанавливать флаги SUID и SGID следует с большой осторожностью и только для программ, которые не имеют возможности запуска произвольных задач.

Суперпользователь (его имя в системе - root), то кто бы ни запустил утилиту passwd(l) на выполнение, во время работы данной программы он временно получает права суперпользователя, т. е., может производить запись в системные файлы, защищенные от остальных пользователей.

Рис. 9:

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

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

Таблица 5. - Дополнительные атрибуты для каталогов:

Код	Название	Значение
t	Sticky bit	Позволяет пользователю удалять только файлы, которыми он владеет или имеет права на запись
s	Set GID, SGID	Позволяет изменить правило установки владельца-группы создаваемых файлов, аналогично реализованному в BSD UNIX

При обсуждении прав доступа отмечалось, что предоставление права на запись в каталог дает достаточно большие полномочия. Имея такое право, пользователь может удалить из каталога любой файл, даже тот, владельцем которого он не является и в отношении которого не имеет никаких прав. Установка атрибута Sticky bit для каталога позволяет установить дополнительную защиту файлов, находящихся в каталоге. Из такого каталога пользователь может удалить только файлы, которыми он владеет, или на которые он имеет явное право доступа на запись, даже при наличии права на запись в каталог. Примером может служить каталог /tmp, который является открытым на запись для всех пользователей, но в котором может оказаться нежелательной возможность удаления пользователем чужих временных файлов.

Атрибут SGID также имеет иное значение для каталогов. При установке этого атрибута для каталога вновь созданные файлы этого каталога будут наследовать владельца-группу по владельцу-группе каталога. Таким образом для UNIX версии System V удается имитировать поведение систем версии BSD, для которых такое правило наследования действует по умолчанию. многопользовательский компьютерный файл

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

Рис. 10:

Таблица 6. - Операции изменения атрибутов файла:

Операция	Команда/системный вызов	Кому разрешено
Изменение прав доступа	chmod(1)	Владелец
Изменение дополнительного атрибута Sticky bit	chmod(1)	Суперпользователь
Изменение дополнитель ного атрибута SGID	chmod(1)	владелец, причем его GID также должен совпадать с идентификатором группы файла

Размещено на Allbest.ru

...