Процессы, права доступа
При доступе процесса к файлу необходимо выяснить, какое отношение имеет данный процесс к данному файлу и какие действия в итоге он может с данным файлом совершать.
Алгоритм этого следующий:
- Если идентификатор пользователя процесса равен идентификатору пользователя файла, то права определяются по первому триплету.
- Если идентификаторы не совпадают, то проверяется, нет ли среди списка групп, в которые входит пользователь процесса, группа файла. Если есть, то используется второй триплет
- Во всех остальных случаях используется третий триплет.
Изменять права доступа к файлам может только владелец (либо суперпользователь -- см. ниже). UID сменить нельзя, GID можно менять только на группу из своего списка групп.
Среди всех UID в системе выделяется один, процессы, выполняемые от лица которого, не используют права доступа (такая организация носит название "система с доверенным субъектом"). Если UID процесса равен 0, то это значит, что процесс выполняется от лица суперпользователя (root) и при любом доступе к файлу он его получает. Соответственно, суперпользователь может устанавливать права доступа, а также UID и GID для любого файла.
По этой причине крайне не рекомендуется выполнять обыденные действия от лица суперпользователя, так как аккаунт суперпользователя предназначен для административных действий. Так же, есть необходимость иметь некоторые запущенные от лица суперпользователя процессы. В дистрибутивах ALT Linux и OWL стараются активно минимизировать их количество.
Вопрос: может ли процесс поменять свой UID? Да, но только если у него сначала был UID = 0. Для этго существует системный вызов setuid. Основное использование этой возможности --- программы для входа пользователя в систему, login или *dm. Они выполняются от лица суперпользователя. После логина порождается новый процесс, у которого меняется UID. Получается стройная система: какие-то программы запускаются "под рутом" (от лица суперпользователя), дальше они работают от лица пользователей. А затем уже UID наследуется. При такой организации пользователь, что бы он не делал, не может повысить себе права (по крайней мере без использования "дыр" в программном обеспечении).
У этой стройной архитектуры есть один изъян --- пользователю иногда бывает необходимо совершать действия от лица суперпользователя. При этом входить в систему как root не хочется, хочется всего лишь запустить от его лица программу. Типичные действия, для которых это нужно --- смена пароля, настройка. Для этого существует механизм получения прав суперпользователя обычным пользователем. А именно, при запуске процесса наследуется UID родительского процесса за одним исключением --- если у файла установлен setuid-бит, и этот файл исполнимый, то при его исполнении процесс получает UID не пользователя, а файла. При отображении прав доступа в формате rwx это обозначается так: rws. Аналогично, можно установить setgid, и процесс будет наследовать вместо основной группы пользователя группу файла.
Также, существует специальная программа sudo, которая позволяет определить список команд, который можно выполнять пользователю от лица другого пользователя. Еще есть более простая программа, su, которая позволяет изменить ID пользователя в активном шелле.
При таком механизме работы пользователь может удалить файл из своего каталога, даже если этот файл чужой. Таким образом появляется опасное место --- /tmp. Для предотвращения такого поведения можно установить sticky bit --- в каталоге, для которого он установлен, и в его подкаталогах, нельзя удалять чужие файлы.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
90 |
1 |
1 |
1 |
|
1 |
MaximByshevskiKonopko, VladimirLysikov, MaximByshevskiKonopko |
|
|