Когда процесс открывает файл в файловой системе, on-disk inode загружается в память и превращается в in-core inode. Когда последний модифицируется, он трансформируется обратно в on-disk inode и сохраняется в файловой системе[40].
in-core inode и on-disk inode не содержат абсолютно одинаковую информацию. Так, например, только in-core inode отслеживает, сколько процессов в системе в данный момент используют файл, ассоциированный с ним.
Когда in-core inode и on-disk inode синхронизируются ядром, большинство системных вызовов завершаются обновлением этих узлов. Когда такое происходит, мы просто будем говорить об обновлении узла; это подразумевает, что изменением затронуты как in-core inode, так и on-disk inode. Некоторые файлы (такие как неименованные каналы), не имеют on-disk inode. В этом случае обновляется только in-core inode.
Имя файла существует только в каталоге, который связывает имя с on-disk inode. Вы можете воспринимать об именах файлов, как об указателях на дисковые узлы для файлов, ассоциированных с ними. Дисковый узел содержит в счетчике ссылок количество имен файлов, которые на него ссылаются. Когда файл удаляется, счетчик ссылок уменьшается на единицу, и если достигает 0, и ни один процесс не держит его открытым, то занятое файлом пространство освобождается. Если же другие процессы держат файл открытым, дисковое пространство освобождается тогда, когда последний из них закрывает файл.
Все это делает доступными следующие возможности.
• Можно иметь множество процессов, имеющих доступ к файлу, который не существует в файловой системе (такому, например, как канал).
• Можно создать файл на диске, удалить его вход в каталоге и продолжать выполнять чтение и запись файла.
• Можно изменить /tmp/foo и немедленно увидеть изменения в /tmp/bar, если оба имени файла ссылаются на один узел.
Система Unix всегда работала описанным образом, хотя эти операции и могут привести в замешательство новых пользователей и программистов. До тех пор, пока вы помните, что имя файла — это всего лишь указатель на дисковый узел, а сам узел — реальный ресурс, с вами все будет в порядке.
Каждый файл в системе имеет как тип (вроде неименованного канала или символьного устройства), так и набор прав доступа, определяющих, какие процессы могут иметь доступ к файлу. Тип файла и права доступа комбинируются в 16-битное значение (тип short в С), называемое режимом файла (file mode).
Младшие 12 бит режима файла представляют права, регламентирующие доступ к файлу, или модификаторы доступа. Они служат для множества функций. Наиболее важной функцией является возможность изменять идентификатор эффективного пользователя и идентификаторы групп файла при его выполнении.
Режим файла обычно записывается в виде шести восьмеричных разрядов. Представленные в восьмеричном виде, три младших разряда содержат модификаторы доступа файла, а два старших разряда указывают на его тип. Например, файл с режимом 0041777 имеет тип 04, модификатор прав 1 и биты доступа 0777[41]. Аналогично, файл с режимом 0100755 имеет тип 010, не имеет установленного модификатора доступа, а правами доступа к нему являются 0755.
11.1.1. Права доступа к файлу
Каждый из этих трех разрядов доступа представляет права для разных классов пользователей. Первый разряд — это права владельца файла, второй — права пользователей, входящих в группу, к которой относится файл, а последний разряд представляет права доступа для всех остальных пользователей. Каждый восьмеричный разряд образован из трех бит, представляющих права на чтение, на запись и на выполнение — от более значащего к менее значащему биту. Термин мировой доступ (world permission) обычно используется для обозначения прав, представленных всем трем классам пользователей.
Попробуем немного конкретизировать последний абзац с помощью нескольких примеров. Команда Linux chmod дает возможность пользователю специфицировать режим доступа в восьмеричном виде и затем применить его к одному или более файлам. Если имеется файл somefile, который мы хотим сделать доступным для записи только его владельцу, а всем пользователям (включая владельца) разрешить его чтение, мы должны использовать режим 0644 (помните, это восьмеричные цифры). Ведущая цифра 6 — это в двоичном виде 110, а это означает, что тип пользователя, к которому она относится (в данном случае — владелец), имеет право как читать, так и писать в файл; 4 в двоичном виде выглядит как 010, что дает остальным пользователям (членам группы и прочим) права только для чтения.
$ chmod 0644 somefile
$ ls -l somefile
-rw-r--r-- 1 ewt devel 31 Feb 15 15:12 somefile
Если мы хотим позволить любому члену группы devel писать в файл, то должны использовать режим 0664.
$ chmod 0664 somefile
$ ls -l somefile
-rw-rw-r-- 1 ewt devel 31 Feb 15 15:12 somefile
Если somefile — сценарий оболочки (программы, которые используют #! в начале для указания командного интерпретатора), который мы хотим запускать на выполнение, необходимо сообщить системе, что файл является исполняемым, включив бит выполнения — в данном случае мы позволяем владельцу читать, писать и запускать файл, а членам группы devel — читать и запускать этот файл. Всем другим пользователям запрещено манипулировать файлом любым образом.
$ chmod 0750 somefile
$ ls -l somefile
-rwxr-x--- 1 ewt devel 31 Feb 15 15:12 somefile
Каталоги имеют тот же набор бит доступа, что и нормальные файлы, но со слегка отличающейся семантикой. Права чтения разрешают процессам доступ к самому каталогу, что дает возможность пользователям получать список содержимого каталога. Права на запись позволяют процессу создавать новые файлы в каталоге и удалять существующие. Бит выполнения, однако, не транслируется так однозначно (что вообще должно означать выполнение каталога?). Это позволяет процессу осуществлять поиск в каталоге, а это означает, что он может иметь доступ к файлу в каталоге, если он знает имя этого файла.
Большинство системных каталогов на машинах Linux имеют права доступа 0755 и принадлежат пользователю root. Это дает возможность пользователям системы просматривать файлы в каталоге и получать доступ к ним по имени, но разрешает запись в каталоги только пользователю root. Анонимные ftp-сайты, которые позволяют любому пользователю отправлять файлы, но не дают возможность им загружать их до тех пор, пока администратор не просмотрит их содержимое, обычно устанавливают права на входящие каталоги в значение 0722. Это позволяет всем пользователям создавать новые файлы в каталоге, не предоставляя им возможность ни видеть содержимое каталога, ни получать доступа к файлам.
Дополнительную информацию о правах доступа к файлам можно найти в любой книге по Linux или Unix.
11.1.2. Модификаторы прав доступа к файлам
Модификаторы прав доступа файлов — это также битовые маски, значения которых представляют биты setuid, setgid и sticky-бит ("липкий" бит). Если бит setuid установлен для исполняемого файла, то эффективный идентификатор пользователя процесса устанавливается равным идентификатору владельца файла, когда программы выполняется (в главе 10 можно найти информацию о том, почему это удобно). Бит setgid ведет себя аналогичным образом, но устанавливает эффективный идентификатор группы в значение группы файла. Бит setuid не имеет значения для неисполняемых файлов, но если бит setgid устанавливается для неисполняемого файла, любая блокировка, выполняемая над файлом, носит обязательный, а не рекомендательный характер (см. главу 13). В Linux биты setuid и setgid игнорируются для сценариев оболочки, поскольку устанавливать setuid для сценариев было бы опасно.
Ни setuid, ни setgid не имеют очевидного смысла для каталогов. И setuid действительно не имеет семантики установки для каталогов. Если же для каталога установлен бит setgid, то все новые файлы, созданные в этом каталоге, будут принадлежать к той же группе, которая владеет самим каталогом. Это облегчает применение каталогов для организации совместной работы пользователей.
Sticky-бит — последний значащий бит в разряде модификатора доступа к файлу, имеет интересную историю, связанную с его наименованием. Старые реализации Unix должны были загружать в память всю программу целиком, прежде чем начать выполнять ее. Это означало, что крупные программы отнимали значительное время на запуск, что было довольно-таки неприятно. Если же программа имела установленный sticky-бит, то операционная система пыталась сохранить ее "привязанной" в памяти настолько долго, насколько возможно, даже когда эта программа не запущена, чтобы уменьшить время запуска. Хотя это было немного некрасиво, но работало достаточно хорошо с часто используемыми программами, такими как компилятор С. Современные реализации Unix, включая Linux, используют загрузку по требованию — кусочек за кусочком, что сделало sticky-бит излишним, поэтому Linux игнорирует его для обычных файлов.
