Что делать если этого не хватает?
Рассмотренная система ограничения доступа к файлам и директориям,
конечно, имеет свои недостатки.
Первый круг проблем связан с тем, что система делит всех юзеров
только на три категории. Причем только вторая категория представляет
собой "четко очерченную" группу юзеров.
Первая категория состоит только из одного юзера - владельца, и ее
права не так-то просто "размазать" на группу юзеров.
Третья же категория состоит вообще из всех юзеров, зарегистрированных на данной машине, то есть границ не имеет.
Если возникнет задача - наделить разными правами (по отношению к
конкретному файлу) разные группы юзеров, причем это именно группы, а не "отдельный юзер" и не "все зарегистрированные юзеры", то возникнут проблемы даже у root'а.
Второй круг проблем связан с тем, что составлять группы может только root. Поэтому, если владелец файла захочет по своему усмотрению
распределить права на свой файл различным юзерам, то оказывается, что он практически не имеет для этого никаких механизмов.
Он может "закрыть" файл от всех или, наоборот, "открыть" его всем. Наличие такой категории как "группа допущенных" не очень-то помогает,
поскольку поменять состав этой группы "рядовой юзер" не сможет.
Ну, первый круг проблем, на самом деле - не проблема :-).
Если не сочинять нереальные ситуации (например, одна группа только читает,
вторая - только выполняет, третья - только пишет, четвертая - только
пишет и выполняет и т.п.), то оказывается, что в реальных ситуациях
может возникнуть необходимость в одной дополнительной группе (кроме владельца,
обычной группы и "всех остальных").
Например, "все остальные" не должны иметь никакого доступа к файлу, но при этом должна быть группа, которым файл доступен на чтение и группа,
которым файл доступен также для записи.
Другой разновидностью задачи может быть исполняемый файл, который
целая группа может модифицировать (то есть иметь право на запись),
другая группа может исполнять, но не изменять и, опять же, "все остальные"
не должны иметь никаких прав на этот файл.
Есть по крайней мере два решения.
Первое состоит в том, чтобы "размазать" права владельца на группу.
Обычно, владелец отличается тем, что имеет право записи (модификации
файла). Соответственно, "группе допущенных" можно дать права только
для чтения (и/или исполнения) файла, а "всем остальным" вообще не давать
никаких прав.
Так вот. Если для изменения файла можно использовать только одну
определенную программу, то надо сделать эту программу (или ее копию)
"суидной", то есть такой, которая при выполнении меняет свой "эффективный
userID" на ID владельца. Естественно, владельцем такой программы должен
быть тот же юзер, что и владелец файла, который мы хотим модифицировать,
а права на запуск этого файла надо дать только той группе, которой мы
хотим дать права на модификацию. Кстати, "владелец" файла может быть
и фиктивным юзером, то есть зарегистрированным в системе только для
этой цели и не соответствовать никакому реальному человеку.
Таким образом, нужно создать две разные группы, в первую (writers) внести только тех юзеров, которые имеют право изменять файл, а во вторую
(readers) тех, кто может только читать файл (ну и всех из writers, пожалуй,
тоже).
Сам файл должен быть открыт для записи только владельцу (это может быть кто-нибудь из группы writers или вообще фиктивный юзер), для чтения -
"группе допущенных" и это должна быть группа readers, и, наконец, для
"всех остальных" можно смело убирать любые права. Ну, а та программа,
которая предназначена для модификации, должна иметь того же владельца,
что и исходный файл, группу - writers, быть "суидной" и права на запуск
должны быть только у группы и владельца (хотя, если он фиктивный, то ему
не обязательно).
Второе решение заключается в том, что файл надо "спрятать" в директорию, с соответствующими правами доступа.
Пусть у нас так же существуют две группы readers и writers, причем все члены группы writers входят также и в readers (но не наоборот :-).
Тогда директория, в которую прячется файл должна иметь группу
readers (кто владелец в общем-то - не важно). Причем для группы доступ
в директорию открыт, а для "всех остальных" закрыт. Это означает,
что в директорию смогут войти только "читатели" и "писатели" (поскольку
они входят в группу "читателей").
А сам файл должен иметь группу writers, причем этой группе файл
должен быть открыт для записи. А право "только чтение" можно дать
категории "все остальные", все равно это будут только те, кто входит
в readers, но не попал в writers. Посторонние просто не попадут в эту
директорию и даже не увидят, что такой файл существует.
Что можно сказать о втором круге проблем (невозможность самим
владельцам файлов определять круг допущенных к файлу)?
Здесь все несколько хуже. Проблема даже не в том, что рядовой юзер
не может сам менять состав групп. Эту то проблему можно решить
достаточно просто. Можно было бы для каждого юзера завести отдельную
группу (кстати, программа для добавления юзера adduser, так и предлагает
делать) и написать специальную программу (естественно, "суидную"),
которая исполнялась бы с правами root'а и позволяла юзеру менять состав
группы, но не любой, а только его личной.
Однако, не торопитесь это делать. Проблема в том, что отдельный
юзер может быть полноправным членом только 16-и групп. И если у юзера
vasia окажется слишком много друзей, которые захотят включить его
в свои группы, то реально он сможет "дружить" только с шестнадцатью,
чьи группы будут первыми в списке групп.
Кроме того, это не решает проблему, если владелец файла захочет
дать разные права нескольким разным группам.
Во-первых, если такое желание юзера не каприз, а вытекает из
потребности организации (например, два отдела могут "подглядывать"
в документы друг друга, но не менять их, при этом все остальные
не должны даже смотреть), то имеет смысл обратиться к администратору.
Пусть он создаст новые группы и определит их состав.
Если же у юзера просто ежедневно меняются симпатии и антипатии
к другим юзерам этой же машины, то тут помочь практически нечем.
Если уж надо "спрятать" файл от кого-то из членов группы, придется
прятать от всей группы. Можно еще воспользоваться "полусекретными"
директориями, как описано в
"Странные" сочетания битов доступа..
И напоследок несколько слов о механизме, который решает все описанные проблемы, но, к сожалению, отсутствует во многих Юниксах (в том числе
и в FreeBSD).
Речь идет о "Списках управления доступом" (Access Control Lists).
Например, в AIX (клон Юникса фирмы IBM) владелец файла может
для любого файла составить такой список (acl). По умолчанию, у файла
такой список отсутствует. Но, при желании, владелец файла может с помощью
специальной утилиты (acledit) "включить" файлу acl и занести туда отдельных юзеров и/или группы, для которых он хочет задать особые права на файл.
Естественно, он может как "расширить" права отдельным юзерам (например,
дать право записи), так и "сузить" (то есть, наоборот - убрать все
права доступа для отдельных юзеров).
Права задаются так же, как для отдельной категории юзеров в обычных файлах, то есть - тройка битов rwx.
При наличии acl'я система определяет права конкретного юзера по отношению к файлу в следующем порядке
- если юзер есть в списке, то права берутся оттуда
- если юзера нет в списке, но есть группа, членом которой он является, то применяются права для этой группы
- и, наконец, если ни юзера, ни группы в списке нет, то проверяются обычные permissions для этого файла.
Итак. Если описанные выше решения проблем вас никак не удовлетворяют, то могу дать еще один совет - смените Юникс, на такой, который
поддерживает acl. Или ждите, пока эта поддержка появится в вашем любимом
клоне Юникса. :-)
Иван Паскаль pascal@tsu.ru
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
