Основы

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

Права доступа

В качестве бонуса для тех, кто более-менее в танке, лектор расскажет ...

Азы. Азы состоят в следующем: пользователи в Линух-системе отличаются в первую очередь друг от друга двумя вещами: есть понятие login name и есть user id. Между ними существует путаница. В общем случае одно не есть другое. Тем не менее, если мелко всё это видеть, то можно приравнять одно к другому. Логин набираем при регистрации в системе, оно текстовое (повелось, что это маленькие латинские буквы), оно хранится в /etc/passwd с качестве первого поля. В этом же файле каждому имени соответсвует user id (вообще, реальная ситуация, когда несколько имён соотв одному user id). Зачем это нужно? Это нужно, чтобы разобраться, какой ресурс какому пользователю принадлежит. Этот user id --- некий идентификатор, указывающий на пользователя. Присваивается процессам и файлам всем, наличествующим в системе. Задача ФС: обеспечить достаточную информацию в поле метаинф. графы имя хранение user id. Что касается процессов, то это задача системы.

Зачем это надо: когда процесс что-то делает с файлом, вступает в силу информация какому пользователю принадлежит процесс и файл. Вот эти самые идентификаторы, которые участвуют, одинаковые на файл и процесс. По крайней мере, по умолчанию, не используются идентификаторы файла и правила, кто с ним что может делать, это может быть в качестве расширения, оно есть в посих ACL. Далее можно ввести такое бинарное деление: если uid процесса и файла совпадают, то будем считать, что процесс - хозяин файла, иначе файл для процесса чужой, и принятие решение будет на основании того, что файл чужой. Под файлом имеется в виду любой объект ОС. Здесь берём файлы как наиболее распространённый вид объектов. Какая проблема с простейшим бинарным делением: есть PUID, FUID, мой-немой файл. В случае, если мой файл, то разрешаю только чтение и запись, если чужой, то хозяин разрешил только чтение. Это субъект-субъектная модель доступа ... . Чем это плохо: иногда удобно организовать доступ сразу для нескольких уидов, например, хорошие пользователи имеют право писать, плохие --- нет. Не нарушая модели, вводятся пользователи. В /etc/passwd /etc/group записан список пользователей, членом группы которых они являются. Заметка: это не единственное место, с помощью PAM можно прикручивать произвольные бэкенды. Первая группа указывается в /etc/passwd, остальные опциональны. И дополнительно указываются права для группы.

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

Теперь временно отвлекаемся... Итак, очень простой, трёхступенчатый алгоритм: у файла есть UID и GID, у процесса есть владелец и список групп, членом которых он является. Если совпадают UID, то файл считает принадлежащим пользователю. Если UID не совпадают, но есть совпадающие группы, то файл считается принадлежащим группе. Иначе файл чужой. Итого, три категории доступа: владелец(u), группа(g), другие(o).

Всего прав три: чтение(r), запись(w) и использование(x). Что касается файлов, то очевидно, что означают эти права. Использование для разных файлов означает разное: если это файл в бинарном формате (ELF), то понятно, что значит запустить его: загрузить, передать. Если это ... , то можно зарегистрировать запускатель. Если файл текстовый, то шелл пытается его исполнить. Есть тонкость, как эти права интерпретируются для каталога: есть такая замечательная команда ls при листинге с ключом -l показывает в правах у директорий первую букву d. Что такое директория? Это специальный файл, он просто другого типа, тип каталог. В этом файле на самом деле хранятся всего две веще: список имён, которые считаются принадлежащими этому катологу, а так же, как этот файл лежит на диске. Уникальным идентификатором файла является не имя, которых может быть много, а индексный дескриптор. Буква r позволяет прочитать список имён. Буква w означает право изменить этот список. То есть, если есть право на запись в каталоге, то можно переименовать файл, удалить его. Если есть право на использование, то можно осуществить доступ к файлу в каталоге. Это значит, что: если права dr--, то какие файлы там лежат, увидите, а прочитать из файла не сможете, то есть, получить индексный дескриптор. Обратная ситуация: если есть только право на использование (--x), то нельзя получить список файлов, но если вы знаете имя, то можно его открыть. Обычно права на каталог есть и на использование и на чтение. В частности, если в каталоге, который ваам доступен на запись, есть файл, на который прав нет, то его можно удалить из этого каталога. Но это не обязательно значит, что это удаление файла, потому что это может быть не последнее имя файла.

Сведения о ресурсах

CategoryLectures CategoryCmc CategoryUneex