Еще о файлах и правах доступа
Жесткие ссылки
Жетские ссылки (hardlink) -- это записи имен в каталогах (мы помним, что каталог это тот же файл, только своего типа), которые ссылаются на один и тот же индексный дескриптор (inode) этой файловой системы. Все жесткие ссылки на файл выступают равноправными именами его. файл существует на диске до тех пор, пока не будет удалено последнее из его имен. Число имен файла отображается выводе команды ls -l, в первой позиции для каждого файла.
Зачем нужны жесткие ссылки? # Если есть программа, которая меняет свое поведение в зависимости от имени (она его сможет прочитать в argv[0]). Тогда можно снабдить ее несколькими именами. Для чего это нужно --- экономить байты # Когда один и тот же файл лежит в разных каталогах. Тогда какой-то пользователь может каким-то файлом попользоваться и удалить, а у других он останется. <!-- 3. Если нужно условно говоря написать конфиг, но специфичность его такова, что это специфичной функции типа маллок, и там может быть например, что забивать --- это симлинк -->
Cимвольные ссылки
Жесткие ссылки это хороший инструмент, но у него есть два крупных недостатка: * Вы не можете по определению создать жесткую ссылку на файл, расположенный в другой файловой системе (т.к. жесткая ссылка влкючает в себя inode, а их нумерация в каждой ФС своя) * Вы не можете создать жесткую ссылку на каталог, это запрещено. Почему это решили запретить: предположим, у нас есть каталог d1, а в нем d2, ссылающийся на тот же inode, что и d1. Фактически, для одного объекта есть два имени: d1 и d1/d2. Можете представить себе рекурсивный обход каталогов: d1, потом d2, потом снова d2, потом снова d2, и так, пока память не кончится. И поскольку вы никогда не сможете отличить, какое из имен главное, а какое дополнительное, то так делать запрещено.
Для решения этих проблем есть другой объект ФС: символьная ссылка (такие файлы в выводе ls -l обозначаются символом l в первой позиции). Это файл, в котором хранится путь к некоторому другому файлу. При обращении к файлу-ссылке имя самого этого файла заменяется на его содержимое: например, если файл-ссылка .../f1 содержит значение d2/f3/, то обращение фактически будет к .../d2/f3/. И, наконец, если значение файла-ссылки начинается на /, то на его содержимое будет заменен весь этот путь.
Символьные ссылки придуманы для того, чтобы обойти оба ограничения жестких ссылок. Здесь любая программа точно сможет отличить символьную ссылку, и большинство вменяемых программ (по умолчанию) по ним не ходят.
Может возникнуть такая специфическая задача. Может потребоваться отладочный конфиг-файлы, например, для функции malloc. В trusted системах бывает нужно, чтобы malloc всегда возвращал память чистую, заполненную нулями. Это можно настроить в некотором конфиг-файле и попросить malloc при каждом вызове читать настройки из этого файла. Однако же, действие это состоит из трех операций (открыть файл, прочитать настройки, закрыть файл), это много, особенно если вызовы malloc происходят часто. Известно, что символьной ссылке в качестве значения можно прописать все что угодно, это необязательно должен быть реально существующий файл. Так вот, можно прописать в нее нужную нам конфигурационную строчку, и тогда для чтения ее потребуется не три файловых операции, а одна: readlink().
Access Control List (ACL)
В UNIX используется субъект-субъектная модель разграничения доступа со множественным субъектом. Все объекты в файловой системе нумеруются по одному и тому же списку --- множественных субъектов. Субъекты бывают как уникальные --- пользователи, так и множественные, т.е. группы. И все права субъектов вычисляются по простой арифметике (3x3, было на прошлой лекции). Все это в общем довольно естественный способ задания прав доступа, тем не менее, существует несколько use case'ов (случаев использования), когда субъект-субъектная модель работает неудобно.
Например, если какому-то конкретному пользователю надо что-то конкретное запретить, например, доступ к некоторому файлу. Это можно реализовать и в модели: для этого надо создать специальную группу, занести туда всех пользователей, кроме провинившегося, и назначить этому файлу, например, такие права: rwxrwx---
Но есть теоретическое обоснование, почему эта модель неполная: когда для некоторого файла одной группе надо дать права только на запись, другой --- только на чтение, этого в ней сделать никак нельзя. Наметим, в какой парадигме она решается: нужна уникальная идентификация не только пользователя, но и объекта. Чтобы облегчить/усложнить себе жизнь, можем еще ввести множественные объекты, т.е. группы объектов. Эти уникальные и групповые идентификаторы объектов к пользователям отношения не имеют. И на основе этих 4 таблиц: пользователей, групп пользователей, объектов, групп объектов, можно изобразить права, кто что с чем может делать. Тогда эта задача вполне легко решается.
Такой объектный способ доступа стандартизован в POSIX, называется ACL (access control list), и слово list выдает нам его особенность. В субъект-субъектной модели вместе с каждым объектом нужно хранить фиксированное, малое количество информации касательно прав доступа --- 9 битов плюс еще идентификаторы пользователя и группы, суммарно в районе 70 бит), а в этой модели, информации может быть столько, что на сами объекты на диске места останется с гулькин нос.
Чтобы это обойти, в ACL вводятся разного рода механизмы: групповые политики, правила наследования, и т.п. .... Но это сильно загромождает понимание того, кто что в итоге может, особенно введение наследования. Не смотря на то,что оно поддерживается большинством Linux-систем, пользоваться ей надо в исключительных случаях. Был случай, когда школьники пришли на олимпиаду по программированию, а им всем оказался разрешен доступ на сетевой диск на запись, именно из-за какой-то ошибки в ACL.
Соответствующие команды (если нужный пакет установлен) называются getfacl/setfacl.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
0 |
1 |
1 |
1 |
|
1 |
|
|