Пользователи, группы и права доступа

В предыдущих темах мы создавали файлы и каталоги, копировали и просматривали их. В теме 2 уже встречался вывод ls -l, в котором после типа записи стоит строка из десяти символов вроде -rw-r--r--. Эта тема объясняет, что означает эта строка и кто решает, может ли программа прочитать файл, записать в него или запустить. Вопрос «кому что разрешено» старше Linux: система UNIX в 1970-х годах задумывалась как многопользовательская, и её модель защиты стала образцом для последующих систем ¹.

Изложение построено от общего к частному. Сначала рассмотрим, как система представляет пользователей и группы и где хранятся эти сведения: файлы /etc/passwd, /etc/group и /etc/shadow. Затем обсудим суперпользователя root, команды su и sudo и причины, по которым работать под root не следует. Основная часть темы посвящена правам доступа к файлам и каталогам, их записи в символьном и восьмеричном виде, маске umask и специальным битам setuid, setgid и sticky. Завершает тему обзор управления учётными записями и списков контроля доступа.

Целевая среда курса — Ubuntu 24.04. Примеры этой темы выполнены в учебной системе Ubuntu 22.04 под учётной записью student, которая входит в группу sudo. Пароль для sudo в этой среде запрашивается, поэтому команды, требующие прав администратора, приведены как пример вывода и помечены явно. Для команд темы вывод в Ubuntu 24.04 совпадает, кроме сообщений adduser, о которых сказано отдельно.

Пользователи и группы в многопользовательской системе

Зачем системе учётные записи

Система, которой пользуются несколько людей и несколько служб, должна знать, кто именно выполняет действие. Учётная запись (англ. user account) — это запись о субъекте, от имени которого выполняются процессы и которому принадлежат файлы. Человек входит в систему под своим именем, веб-сервер работает под отдельной служебной записью, почтовые и системные службы — под собственными записями. Служебные записи обычно не имеют пароля и не позволяют интерактивного входа: их оболочка указывает на /usr/sbin/nologin, программу, которая сразу отказывает во входе.

Группа (англ. group) — именованное множество учётных записей. Права можно выдать группе, а не каждому пользователю отдельно. Если над документами отдела работают пять сотрудников, достаточно одной группы, в которую входят все пять, и одного правила на каталог с документами.

UID и GID: как система видит пользователя

Ядро не работает с именами. Для него пользователь — это число UID (англ. user identifier), а группа — число GID (англ. group identifier). Имена существуют для людей и переводятся в числа по файлам системы. Проверка прав выполняется по числам: если файл принадлежит пользователю с UID 1000, доступ к нему получит процесс, у которого эффективный UID равен 1000. Учётная запись root имеет UID 0, и ядро распознаёт её именно по этому числу, а не по имени.

У каждого процесса есть основная группа и список дополнительных групп. Команда id показывает все эти сведения для текущего пользователя:

id

uid=1000(student) gid=1000(student) groups=1000(student),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(kvm),117(netdev),120(libvirt),122(wireshark),999(docker)

Поле uid=1000(student) содержит число и имя, то же для gid. Поле groups перечисляет все группы, в том числе основную. Группа adm (4) даёт право читать журналы системы в /var/log, группа sudo (27) — право пользоваться командой sudo. Группа docker (999) заслуживает отдельного внимания: её члены могут запускать контейнеры с доступом к файловой системе хоста, что фактически равносильно правам root. Поэтому включать пользователя в такие группы нужно осознанно.

По соглашению системные учётные записи и группы получают числа меньше 1000, пользовательские — начиная с 1000. Конкретные границы задаются в файле /etc/login.defs и могут отличаться в других дистрибутивах.

Файлы /etc/passwd и /etc/group

Сведения об учётных записях хранятся в текстовом файле /etc/passwd. Каждая строка описывает одну учётную запись и состоит из семи полей, разделённых двоеточиями. Посмотрим первые строки файла и строку пользователя student:

head -n 3 /etc/passwd
grep '^student:' /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
student:x:1000:1000:,,,:/home/student:/bin/bash

Смысл полей показан в таблице.

Строка root содержит UID 0 и GID 0, а строка daemon — оболочку /usr/sbin/nologin, то есть учётную запись службы, которая не предназначена для входа. Поле пароля в этих строках состоит из одного символа x, а не из настоящего хеша, и это сделано намеренно, как будет показано ниже.

Группы описаны в файле /etc/group. Его строка тоже содержит четыре поля: имя группы, место для пароля (обычно x), GID и список дополнительных членов группы через запятую:

grep -E '^(root|sudo|student):' /etc/group

root:x:0:
sudo:x:27:student
student:x:1000:

Строка sudo показывает, что пользователь student является дополнительным членом группы с GID 27. Строка student имеет пустой список членов, хотя student состоит в собственной группе. Это не ошибка: основная группа пользователя задаётся полем GID в /etc/passwd, и в список членов её обычно не записывают. Поэтому отсутствие имени в списке группы не означает отсутствия членства. Надёжнее смотреть на результат команды id.

Почему пароль хранится в /etc/shadow

Файл /etc/passwd должен читать любой пользователь: программы берут из него имена, домашние каталоги и оболочки. Если бы хеши паролей хранились в нём, любой пользователь получил бы возможность перебирать пароли на своей машине без ограничений. Поэтому хеши вынесены в отдельный файл /etc/shadow, доступный только суперпользователю и группе shadow:

ls -l /etc/passwd /etc/shadow
cat /etc/shadow

-rw-r--r-- 1 root root    1773 Mar 16  2026 /etc/passwd
-rw-r----- 1 root shadow   985 Mar 16  2026 /etc/shadow
cat: /etc/shadow: Permission denied

Команда cat завершилась отказом «Permission denied»: обычный пользователь не имеет права читать этот файл. Права rw-r----- будут разобраны ниже. Для иллюстрации формата приведём строку того же файла. Это пример вывода: реальный файл читается только root, а значения условные.

student:$y$j9T$условная.соль$условный.хеш:20001:0:99999:7:::

Поля здесь такие: имя пользователя; хеш пароля в формате $идентификатор$соль$хеш, где идентификатор $y$ означает алгоритм yescrypt, а $6$ — SHA-512; дата последней смены пароля в днях, прошедших с 1 января 1970 года; минимальный и максимальный срок действия пароля; количество дней предупреждения; срок неактивности; дата окончания действия учётной записи и одно зарезервированное поле. Пустое поле означает, что параметр не задан. Пароль в файле не хранится: хранится результат односторонней функции от пароля и соли. При входе система вычисляет тот же результат для введённого пароля и сравнивает. Соль — случайная строка, добавляемая к паролю; благодаря ей одинаковые пароли дают разные хеши, и заранее вычисленные таблицы для перебора бесполезны. Подробное описание форматов даёт справочная страница shadow(5) ⁴; общие принципы хранения паролей в UNIX-системах изложены в руководстве по администрированию ³.

Заметим, что поле пароля в /etc/passwd содержит x именно потому, что настоящий хеш находится в /etc/shadow. Если бы в поле стоял хеш, его могли бы прочитать все.

Команды id, groups и who

Команда id показывает UID и группы конкретного пользователя, если его имя передано аргументом: id root выведет данные root. Команда groups печатает только имена групп текущего пользователя:

groups

student adm dialout cdrom floppy sudo audio dip video plugdev kvm netdev libvirt wireshark docker

Команда who показывает, кто сейчас работает в системе; краткое описание базовых команд учётных записей дано в учебнике ². Вывод зависит от состояния системы; пример вывода для одного открытого терминала:

student     pts/0        2026-10-12 13:02 (:0)

Здесь pts/0 — псевдотерминал, через который вошёл пользователь, а (:0) — источник входа. В сеансе, где других входов нет, who ничего не выводит. Такой вывод не означает ошибки.

Суперпользователь и принцип минимальных привилегий

Учётная запись root

Учётная запись root имеет UID 0. Ядро Linux пропускает для неё большинство проверок прав доступа: root может читать и изменять любой файл, завершать любой процесс, менять владельца файлов и загружать модули ядра. Такая учётная запись нужна для администрирования, но её возможности безграничны, поэтому практика администрирования сводится к тому, чтобы использовать их как можно реже и только для конкретных задач ³.

В Ubuntu пароль root по умолчанию не задан, то есть вход напрямую под root закрыт. Администратором становится пользователь, входящий в группу sudo, и привилегии он получает через команду sudo с собственным паролем.

su и sudo

Команда su (англ. switch user) запускает оболочку от имени другого пользователя. Без аргументов она переключает на root и требует пароль root; su - дополнительно создаёт окружение входа, как при настоящем входе в систему. Поскольку пароль root в Ubuntu не задан, su для администрирования применяется редко.

Команда sudo (англ. superuser do) выполняет одну команду от имени root или другого пользователя, предварительно проверив право текущего пользователя. Проверка выполняется по собственному паролю, а правила задаются в файле /etc/sudoers и в каталоге /etc/sudoers.d/. Действие записывается в журнал, поэтому по журналу можно узнать, кто и что выполнял с правами администратора.

Поведение sudo без интерактивного запроса удобно проверить флагом -n, который не спрашивает пароль и сразу завершается с ошибкой, если пароль нужен:

sudo -n true
echo "код возврата: $?"

sudo: a password is required
код возврата: 1

Команда true ничего не делает и завершается с кодом 0 при успехе. Здесь она не выполнена, потому что sudo не получил пароль. Код возврата 1 говорит о неудаче, и это именно та ситуация, которую можно встретить, если попробовать sudo в скрипте без предварительного ввода пароля.

Почему не работать под root

Работа под root постоянно, даже для удобства, создаёт три опасности. Первая — ошибки без ограничений. Команды вроде rm не спрашивают подтверждения ни у обычного пользователя, ни у root, но обычного пользователя от последствий опечатки защищают права: удалить он может только то, что ему разрешено. Для root таких ограничений нет. Команда rm -rf с пустой переменной в пути, рассматриваемая в теме 15, под root может стереть систему целиком.

Вторая опасность — вредоносные программы. Любая программа, запущенная под root, получает полный доступ к системе. Если пользователь запустил под root файл из сомнительного источника, злоумышленник получил систему.

Третья опасность — незаметное искажение прав. Файл, созданный под root, принадлежит root, и обычный пользователь не может его изменить. Рассмотрим типичный пример: пользователь, забыв sudo в одной команде и добавив его в другой, получает файл, который потом не может редактировать.

sudo touch /home/student/notes.txt
ls -l /home/student/notes.txt
echo "строка" >> /home/student/notes.txt

-rw-r--r-- 1 root root 0 Oct 12 13:40 /home/student/notes.txt
bash: /home/student/notes.txt: Permission denied

Это пример вывода: команда требует пароля администратора и на учебной машине не выполнялась. Вывод показывает, что файл принадлежит root, а запись от имени student отклонена. Исправляется это командой sudo chown student /home/student/notes.txt, но правильнее не создавать файлы от имени root вовсе.

Принцип, которому следует эта практика, называется принципом минимальных привилегий (англ. principle of least privilege): процесс или пользователь получает только те права, которые нужны для текущей задачи, и не больше. Администратор, который пользуется sudo только для конкретных команд, применяет этот принцип на практике.

Файл sudoers — обзор

Правила sudo записываются в файл /etc/sudoers и в файлы каталога /etc/sudoers.d/. Строка правила описывает, какой пользователь на каком хосте и от чьего имени может выполнять какие команды. В Ubuntu по умолчанию встречается строка вида %sudo ALL=(ALL:ALL) ALL: символ % означает группу, и члены группы sudo могут выполнять любые команды от имени любого пользователя. Пример строки приведён для понимания; сам файл читается только root.

Редактировать sudoers напрямую опасно: ошибка в синтаксисе может закрыть доступ к sudo. Поэтому файл открывают командой sudo visudo, которая проверяет синтаксис перед сохранением. Подробные правила описаны в справочной странице sudoers(5) и sudo(8) ⁴.

Права доступа к файлам и каталогам

Три класса пользователей и три вида прав

Каждый файл и каталог имеет владельца (пользователя) и группу-владельца. Права доступа задаются для трёх классов: владелец (англ. user, u), группа (англ. group, g) и все остальные (англ. others, o). Для каждого класса существуют три вида прав: чтение (англ. read, r), запись (англ. write, w) и выполнение (англ. execute, x). Значение прав в числовой форме: r — 4, w — 2, x — 1.

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

Разбор строки -rwxr-x---

Строка прав, которую показывает ls -l, состоит из десяти символов. Первый символ задаёт тип записи: - — обычный файл, d — каталог, l — символическая ссылка. Остальные девять символов разбиты на три группы по три: права владельца, группы и остальных. Разберём строку -rwxr-x---, которую создадим командой chmod:

touch g
chmod 750 g
ls -l g

-rwxr-x--- 1 student student 0 Oct 12 13:22 g

Разбор этой строки приведён в таблице.

Иллюстрация ниже показывает ту же строку: каждый символ связан с классом и видом права.

На рисунке видно, что дефис в позиции отсутствующего права заменяет букву. Поэтому r-x означает чтение и выполнение без записи, а --- означает полное отсутствие прав. Восьмеричная запись 750 получается сложением значений по каждому классу: 7 для владельца, 5 для группы, 0 для остальных. Этот переход от строки к числу понадобится при изучении chmod.

Права файла и права каталога

Смысл каждого вида права зависит от того, что за объект перед нами. Для файла права описывают действия с его содержимым. Для каталога они описывают действия с его записями, то есть с именами файлов внутри него. Таблица сводит оба случая.

Из таблицы следует важное правило: для удаления файла нужно право записи в каталог, в котором лежит файл, а не право записи в сам файл. Файл, доступный только для чтения, в каталоге с правом записи можно удалить. Исключение описано в разделе о sticky bit.

Право x у каталога сбивает с толку больше всего. Без него невозможно войти в каталог и обратиться к файлу внутри, даже если права файла разрешают чтение. Проверим это экспериментом. Создадим каталог с файлом и ограничим его права:

mkdir dir
echo data > dir/f.txt
chmod 400 dir
ls dir
ls -l dir
cat dir/f.txt

f.txt
ls: cannot access 'dir/f.txt': Permission denied
total 0
-????????? ? ? ? ?            ? f.txt
cat: dir/f.txt: Permission denied

Права r-- на каталог позволили получить список имён: ls dir вывел f.txt. Однако ls -l не смог прочитать атрибуты файла, потому что для этого нужно право x на каталог. Поэтому вместо прав появились знаки вопроса, а cat отказал в чтении. Заметим, что сообщение об ошибке относится к записи dir/f.txt, хотя сам файл не виноват.

Теперь проверим обратную ситуацию — право x без права r:

chmod 100 dir
ls dir
cat dir/f.txt
cd dir && pwd

ls: cannot open directory 'dir': Permission denied
data
/home/student/perm-demo/dir

Список имён не получен, потому что для него нужно право r. Однако cat dir/f.txt сработал: путь из известного имени вычисляется при праве x, а содержимое файла читается по его собственным правам. Команда cd тоже работает. Такой каталог удобен как «почтовый ящик», в который можно положить файл, но нельзя просмотреть его содержимое. Этим пользуются на практике, хотя такой приём всегда требует осторожности.

Наконец, проверим право записи без права r:

chmod 300 dir
ls -ld dir
ls dir
touch dir/new

d-wx------ 2 student student 4096 Oct 12 13:22 dir
ls: cannot open directory 'dir': Permission denied

Команда touch dir/new выполнилась без ошибки: право wx позволяет создавать записи, хотя список записей недоступен. Все три эксперимента подтверждают, что права каталога и права файла — разные вещи и проверяются раздельно.

Проход по пути: зачем каталогу право x

Когда программа обращается к файлу по пути вроде /home/student/projects/report.txt, ядро проходит весь путь по шагам. На каждом каталоге оно проверяет право x, и только после этого обращается к файлу, проверяя его права r или w. Если хотя бы на одном шаге права x нет, доступ отказывается, даже если файл открыт для всех.

Из этого следует практическое правило. Чтобы выдать доступ к файлам в каталоге /srv/share, недостаточно дать права на сам каталог share: нужно убедиться, что каталог /srv тоже допускает проход. Путь всегда проверяется целиком, и ошибка в одном звене делает недоступным всё дерево внутри.

Числовая и символьная запись прав

chmod в символьной записи

Команда chmod (англ. change mode) меняет права файла или каталога. Символьная запись состоит из трёх частей: класс (u, g, o или a — все), оператор (+ добавить, - убрать, = задать точно) и вид права (r, w, x). Несколько изменений разделяются запятыми.

chmod u+x g
chmod go-w g
chmod a+r g
chmod u=rwx,g=rx,o= g
stat -c '%a %A %n' g

750 -rwxr-x--- g

Команды семейства GNU Coreutils, в том числе chmod, ls и stat, описаны в официальном руководстве ⁶. Команда stat -c '%a %A %n' выводит восьмеричные права, символьные права и имя файла, поэтому её удобно использовать для проверки результата. Последняя запись u=rwx,g=rx,o= задаёт права точно: владелец — rwx, группа — rx, остальные — ничего, и результат совпал с исходной строкой -rwxr-x---. Оператор = удобен тем, что не зависит от предыдущего состояния файла.

Восьмеричная запись

Восьмеричная запись задаёт права тремя цифрами, каждая из которых относится к одному классу. Цифра равна сумме значений прав: r — 4, w — 2, x — 1. Например, цифра 6 означает rw- (4 + 2), 5 — r-x (4 + 1), 0 — отсутствие прав. Тройка 750 означает владелец 7 (rwx), группа 5 (r-x), остальные 0 (---). Ведущий ноль допустим и ничего не меняет: 0640 то же самое, что 640.

chmod 640 g
stat -c '%a %A %n' g

640 -rw-r----- g

Восьмеричная запись компактна и точна, поэтому её предпочитают в скриптах и конфигурациях. Символьная запись удобнее для точечного изменения одного права. Опасной практикой считается выдача chmod 777: она даёт полный доступ всем пользователям системы и почти всегда маскирует реальную проблему с владельцем или группой. Ключ -R меняет права рекурсивно и требует внимательности: если указать её для всего /, результат будет разрушительным. Перед рекурсивной сменой прав стоит проверить путь командой ls.

chown и chgrp

Команда chown меняет владельца файла, а chgrp — группу-владельца. Смена владельца требует прав root, потому что иначе пользователь мог бы «передать» свой файл другому и обойти квоты или учёт. Смена группы разрешена владельцу файла, если он входит в целевую группу. Это позволяет пользователю распределять свои файлы между группами, в которых он состоит.

Смена владельца выполняется от имени администратора. Пример вывода (на учебной машине не выполнялся):

sudo chown alice report.txt
ls -l report.txt

-rw-r--r-- 1 alice student 0 Oct 12 13:45 report.txt

Смена группы, в которой состоит сам пользователь, выполняется без прав администратора. Пример из реального эксперимента:

mkdir share
chgrp adm share
ls -ld share

drwxr-xr-x 2 student adm 4096 Oct 12 13:22 share

Группа adm в этой системе есть, и student в неё входит, поэтому chgrp сработал. Если указать группу, в которую пользователь не входит, команда завершится отказом «Operation not permitted».

umask и права новых файлов

Права нового файла не задаются вручную, а определяются маской umask. Маска — это набор битов, которые снимаются (сбрасываются) в базовых правах при создании. Базовые права равны 666 для файлов и 777 для каталогов. Файлы не получают права выполнения по умолчанию, поэтому базовое значение для них 666, а не 777. Текущую маску показывает команда umask:

umask
umask -S

0022
u=rwx,g=rx,o=rx

Маска 0022 в символьной форме -S означает «запретить запись группе и остальным». Вычисление выполняется по цифрам: в каждой цифре базового значения сбрасываются биты, которые установлены в той же позиции маски. Формально это побитовая операция «базовые права И НЕ маска». Для масок 022, 027 и 077 результат совпадает с обычным вычитанием, поэтому его удобно записывать как разность. Для маски 022 получаем:

• файлы: 666 − 022 = 644, то есть rw-r--r--;
• каталоги: 777 − 022 = 755, то есть rwxr-xr-x.

Проверим на практике с маской 027, где группе запрещена запись, а остальным запрещено всё:

umask 027
touch f027
mkdir d027
ls -ld d027
ls -l f027

drwxr-x--- 2 student student 4096 Oct 12 13:22 d027
-rw-r----- 1 student student 0 Oct 12 13:22 f027

Расчёт для маски 027 такой: файлы 666 − 027 = 640 (rw-r-----), каталоги 777 − 027 = 750 (rwxr-x---). Совпадение с выводом подтверждает расчёт. Для маски 077 получаем 600 и 700, то есть доступ только владельцу. Арифметическое вычитание работает не всегда: при маске 033 оно дало бы для файлов 633, но маска лишь сбрасывает биты w и x, а бита x у файла и так нет, поэтому реальный результат — 644 (rw-r--r--). Проверим это и сразу вернём маску к значению по умолчанию 022, чтобы следующие примеры не зависели от опыта:

umask 033
touch f033
stat -c '%a %A %n' f033
umask 022

644 -rw-r--r-- f033

Маска действует только на вновь создаваемые объекты и не меняет права существующих файлов. Маску задают в профиле оболочки, о котором пойдёт речь в теме 8; значение по умолчанию 022 в большинстве дистрибутивов обеспечивает защиту от записи чужими пользователями.

Специальные биты

setuid

Кроме девяти основных битов, у файла есть три специальных бита: setuid, setgid и sticky. Они записываются в четвёртой (старшей) восьмеричной цифре: setuid — 4, setgid — 2, sticky — 1. В символьной записи setuid проявляется буквой s в позиции x владельца, setgid — s в позиции x группы, sticky — t в позиции x остальных.

Бит setuid на исполняемом файле означает, что программа при запуске получает права владельца файла, а не запустившего её пользователя. Классический пример — команда passwd, которая меняет пароль и записывает результат в /etc/shadow, принадлежащий root. Обычный пользователь не может писать в этот файл, но passwd с битом setuid выполняется с эффективным UID 0 на время своей работы ⁵.

ls -l /usr/bin/passwd
find /usr/bin -perm -4000 -type f 2>/dev/null | head -n 5

-rwsr-xr-x 1 root root 59976 Feb  6  2024 /usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/pkexec
/usr/bin/su
/usr/bin/sudo

В строке прав -rwsr-xr-x буква s стоит на месте x владельца, значит, бит setuid установлен и x тоже установлен. Если бы x не было, буква была бы заглавной S, что означает бессмысленный бит. Команда find с параметром -perm -4000 находит все файлы с установленным setuid. Порядок вывода find зависит от файловой системы, а head -n 5 оставляет только первые пять найденных файлов, поэтому сама passwd в этот фрагмент не попала. Список показывает, что такие программы — это команды, связанные с учётными записями и правами: gpasswd, su, sudo, mount, а также passwd.

Setuid требует осторожности. Ошибка в такой программе даёт злоумышленнику права владельца, поэтому программы с setuid должны быть минимальными и тщательно проверенными. Заметим также, что Linux игнорирует бит setuid на скриптах оболочки: такие скрипты запускаются с правами пользователя, который их вызвал.

setgid

Бит setgid действует по-разному для файлов и каталогов. Для исполняемого файла он означает запуск с правами группы-владельца файла. Для каталога он важнее: новые файлы и подкаталоги, создаваемые внутри, наследуют группу каталога, а не основную группу создавшего пользователя. Это свойство используется для общих каталогов отдела, где все файлы должны принадлежать одной группе, независимо от того, кто их создал.

Проверим на примере общего каталога share, который был создан и передан группе adm в разделе о chgrp. Группу adm выбрали потому, что пользователь в неё входит:

chmod 2775 share
ls -ld share
touch share/report.txt
ls -l share

drwxrwsr-x 2 student adm 4096 Oct 12 13:22 share
total 0
-rw-r--r-- 1 student adm 0 Oct 12 13:22 report.txt

Восьмеричная цифра 2 в 2775 включает setgid. В строке прав буква s стоит на месте x группы. Файл report.txt создан пользователем student, но его группа — adm, то есть группа каталога. Без setgid файл получил бы группу student. Системный пример того же механизма — каталог почты /var/mail с группой mail:

ls -ld /var/mail

drwxrwsr-x 2 root mail 4096 Jan  7  2025 /var/mail

sticky bit

Sticky bit (англ. «липкий бит») на каталоге ограничивает удаление и переименование записей. Без него каждый, кто имеет право записи в каталог, может удалить любой файл в нём, даже чужой. С sticky bit удалить или переименовать запись может только владелец файла, владелец каталога или root. Классический пример — каталог /tmp, в который пишут все пользователи системы:

ls -ld /tmp

drwxrwxrwt 70 root root 16384 Oct 12 13:22 /tmp

Права drwxrwxrwt означают, что все могут создавать файлы в /tmp, но буква t на месте x остальных не даёт удалить чужие файлы. Восьмеричная запись этого режима — 1777, где цифра 1 задаёт sticky bit. Проверим его на собственном каталоге:

mkdir st
chmod +t st
stat -c '%a %A %n' st

1755 drwxr-xr-t st

Заметим разницу: буква t в верхнем регистре T означает, что sticky bit установлен, но право x у остальных отсутствует. Строчная t показывает, что право x есть. Этот нюанс связан с тем же принципом, что и у setuid.

Рисунок показывает, где в строке прав располагаются специальные биты. Заметим, что все три бита занимают те же позиции, что и обычные права x, поэтому их легко спутать с обычным выполнением. Сравнение s и S или t и T позволяет отличить установленный бит от установленного x.

Управление учётными записями и ACL

Создание пользователей и групп

Создание учётных записей и групп требует прав администратора. В Ubuntu для этого есть интерактивная команда adduser и низкоуровневая useradd. Ниже приведён пример вывода adduser (на учебной машине не выполнялся, вывод соответствует версии Ubuntu 22.04; в Ubuntu 24.04 те же сообщения начинаются с префикса info:, а кавычки вокруг имён прямые):

sudo adduser alice

Adding user `alice' ...
Adding new group `alice' (1001) ...
Adding new user `alice' (1001) with group `alice' ...
Creating home directory `/home/alice' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for alice
Enter the new value, or press ENTER for the default
...
Is the information correct? [Y/n] Y

Команда создала группу alice с GID 1001, учётную запись с UID 1001, домашний каталог и запросила пароль. Сведения о новом пользователе появятся в /etc/passwd и /etc/group строками, которые мы разобрали выше.

Добавление пользователя в дополнительную группу выполняется командой usermod. Ключ -a (append) обязателен: без него -G заменит весь список дополнительных групп указанным, и пользователь потеряет членство в остальных группах.

sudo groupadd projectteam
sudo usermod -aG projectteam alice
id alice

Пример вывода (не выполнялся на учебной машине):

uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(projectteam)

Смена пароля своей учётной записи выполняется командой passwd без аргументов, а смена пароля другого пользователя — sudo passwd alice. Изменения членства в группах вступают в силу при следующем входе в систему; в текущем сеансе можно переключить группу командой newgrp.

Пароли и служебные учётные записи

Команда passwd меняет хеш в /etc/shadow и поэтому сама запускается с битом setuid, рассмотренным выше. Служебным учётным записям пароль обычно не назначают, а оболочку ставят /usr/sbin/nologin. Такую запись можно заблокировать командой sudo usermod -L имя и разблокировать командой sudo usermod -U имя; блокировка добавляет в хеш недопустимый префикс, поэтому пароль не может совпасть. Эти команды относятся к администрированию и выполняются только по сценарию администратора.

Списки контроля доступа (ACL) — обзор

Стандартных девяти битов не всегда достаточно. Если нужно дать право записи в каталог двум конкретным пользователям, не входящим в одну группу, применяются списки контроля доступа (англ. access control list, ACL). ACL позволяет задать права отдельным пользователям и группам сверх классов владелец, группа и остальные. Команды setfacl и getfacl входят в пакет acl, который в Ubuntu устанавливается командой sudo apt install acl.

Признаком наличия ACL служит знак + в конце строки прав. Ниже показан вывод для файла с правами 644 после команды setfacl -m u:alice:rw- report.txt (проверено с существующим пользователем вместо alice):

-rw-rw-r--+ 1 student student 0 Oct 12 13:50 report.txt

Подробный вид ACL показывает getfacl:

# file: report.txt
# owner: student
# group: student
user::rw-
user:alice:rw-
group::r--
mask::rw-
other::r--

Строка user:alice:rw- даёт пользователю alice права, которых нет ни у группы-владельца, ни у остальных. Строка mask ограничивает максимальные права для всех именованных записей. ACL не заменяет обычные права, а дополняет их, поэтому при сложной схеме доступа разобраться в ней труднее. Для курса достаточно понимать принцип и уметь распознать признак +; подробности оставлены для самостоятельного изучения по справочной странице acl(5) ⁴.

Мандатный контроль доступа: AppArmor и SELinux

Ограничения дискреционного контроля (DAC vs MAC)

Классическая модель прав Linux и POSIX ACL относится к дискреционному управлению доступом (англ. Discretionary Access Control, DAC): владелец файла по своему усмотрению решает, кому предоставить права чтения, записи или выполнения. Однако у DAC есть фундаментальная слабость — всемогущество суперпользователя и процессов, запущенных от его имени. Если веб-сервер Nginx или СУБД скомпрометированы через уязвимость переполнения буфера (RCE), процесс с правами root получает неограниченный доступ ко всей операционной системе.

Для нейтрализации этой угрозы разработан мандатный контроль доступа (англ. Mandatory Access Control, MAC) на базе архитектуры модулей безопасности ядра LSM (Linux Security Modules) ⁵⁸. В модели MAC централизованная политика безопасности диктуется ядром и действует принудительно, даже если процесс запущен от имени root:

• суперпользователь не может обойти ограничения политики MAC;
• скомпрометированный демон веб-сервера не может прочитать файл /etc/shadow или домашние каталоги пользователей, даже если права DAC формально разрешают чтение;
• процессы изолируются в минимально необходимых им доменах выполнения (принцип минимальных привилегий).

Режимы работы и реализации: AppArmor и SELinux

В мире Linux закрепились две ведущие системы MAC ⁷⁸:

1. AppArmor (по умолчанию в Ubuntu, Debian, SUSE): ориентирован на пути к файлам. Для каждой защищаемой программы в каталоге /etc/apparmor.d/ создаётся текстовый профиль, описывающий разрешённые исполняемые файлы, сетевые сокеты и пути к файлам с флагами доступа (r — чтение, w — запись, px — запуск с отдельным профилем).

   • Профиль может находиться в одном из двух режимов: Enforce (нарушения блокируются ядром с записью в системный журнал) или Complain (нарушения только логируются без блокировки, что применяется при отладке).
   • Текущее состояние профилей проверяется командой sudo aa-status. Перевести профиль в строгий режим можно утилитой sudo aa-enforce /path/to/profile.

2. SELinux (Security-Enhanced Linux, по умолчанию в RHEL, CentOS, Rocky Linux, Fedora): архитектура строгой типизации (Type Enforcement), разработанная Агентством национальной безопасности США (NSA) ⁸. В SELinux каждый объект системы (файл, процесс, сокет, порт) маркируется многокомпонентной меткой — контекстом безопасности:

   user:role:type:level
   

   Для безопасности ключевую роль играет поле type (тип файла или домен процесса). Например, файл веб-страницы маркируется типом httpd_sys_content_t, а процесс веб-сервера исполняется в домене httpd_t. Ядро разрешает процессу httpd_t чтение только тех файлов, тип которых явно указан в матрице политик. Если атакующий через уязвимость веб-сервера пытается прочитать файл базы данных с типом postgresql_db_t, ядро немедленно блокирует операцию на уровне системного вызова, генерируя событие AVC (Access Vector Cache) Denial.

   • Просмотр контекстов безопасности выполняется флагом -Z стандартных утилит: ls -Z /var/www или ps -eZ | grep nginx.
   • Режимы SELinux: Enforcing (принудительное соблюдение), Permissive (только журналирование) и Disabled. Проверить режим позволяет команда getenforce, а временно переключить — sudo setenforce 0 (Permissive) или sudo setenforce 1 (Enforcing). Восстановление эталонных меток на файловой системе выполняется утилитой restorecon -Rv /path.

Модульная подсистема аутентификации PAM

В ранних версиях UNIX каждая программа, требующая проверки подлинности (login, passwd, su), содержала собственный закрытый код чтения /etc/passwd и проверки паролей. Это исключало гибкую модернизацию: добавление биометрии, LDAP, смарт-карт или двухфакторной аутентификации (2FA) требовало перекомпиляции десятков системных утилит.

Эту проблему решила архитектура PAM (Pluggable Authentication Modules) Самара и Шемерса ⁹, стандартизованная в Linux. Программа передаёт задачу проверки подлинности библиотеке PAM, а логика проверки задаётся декларативными конфигурационными файлами в каталоге /etc/pam.d/.

Структура конфигурации /etc/pam.d/

Каждой службе соответствует отдельный конфигурационный файл (например, /etc/pam.d/login, /etc/pam.d/sshd, /etc/pam.d/sudo). Каждая строка конфигурации состоит из четырёх полей:

тип_модуля    флаг_управления    имя_библиотеки_модуля    [параметры]

1. Тип модуля (Management Group):

   • auth: аутентификация пользователя (запрос пароля, токена, биометрии) и установка полномочий (credentials);
   • account: авторизация учётной записи (не истёк ли срок действия пароля, разрешён ли вход в данное время суток);
   • password: смена пароля (проверка на сложность по словарю, проверка длины и истории повторов);
   • session: подготовка и очистка окружения пользователя (монтирование домашнего каталога, настройка лимитов limits.conf, вывод приветствия).

2. Флаги управления (Control Flags):

   • required: модуль обязателен к успешному прохождению. В случае неудачи проверка продолжается по остальным модулям цепочки (чтобы нарушитель не догадался по времени ответа, где именно произошёл сбой), но итоговый вердикт будет отрицательным.
   • requisite: модуль критически обязателен. При первой же ошибке цепочка немедленно прерывается с отказом в доступе.
   • sufficient: если этот модуль вернул успех (и ни один из предшествующих required не завершился сбоем), цепочка завершается успехом без проверки последующих модулей.
   • optional: результат модуля игнорируется, если только он не является единственным в цепочке.

Защита от атак подбора паролей: модуль pam_faillock

Для защиты от атак полного перебора паролей (англ. brute-force attacks) в Linux используется модуль pam_faillock (пришедший на смену pam_tally2). Модуль отслеживает число последовательных неудачных попыток ввода пароля для каждого пользователя и блокирует учётную запись на заданное время.

Типовое включение в /etc/pam.d/system-auth или common-auth:

auth    required    pam_faillock.so preauth audit silent deny=5 unlock_time=900
auth    sufficient  pam_unix.so try_first_pass
auth    [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

Параметр deny=5 блокирует вход после 5 неверных попыток, а unlock_time=900 автоматически снимает блокировку через 15 минут (900 секунд). Администратор может просмотреть счётчик заблокированных пользователей утилитой faillock --user <имя> и сбросить блокировку командой faillock --user <имя> --reset.

Итоги темы

Пользователи в Linux представлены числами UID и GID, а имена существуют для людей и переводятся в числа по файлам /etc/passwd и /etc/group. Хеши паролей вынесены в /etc/shadow, который читает только root, поскольку файл /etc/passwd должен быть доступен всем. Суперпользователь root обладает почти неограниченными возможностями, поэтому администрирование выполняют через sudo, а повседневную работу ведут под обычной учётной записью, соблюдая принцип минимальных привилегий.

Права доступа задаются для владельца, группы и остальных тремя видами rwx. Смысл прав зависит от объекта: для файла они управляют содержимым, для каталога — списком имён и входом в каталог. Право x на каталог необходимо для прохода по любому пути внутри него, и отсутствие этого права делает недоступным всё содержимое, даже при разрешённом чтении файлов. Права задаются командой chmod в символьной или восьмеричной записи, а права новых файлов определяются маской umask, которая сбрасывает биты в базовых значениях 666 и 777.

Специальные биты setuid, setgid и sticky меняют поведение программ и каталогов: setuid позволяет программе работать с правами владельца, setgid — сохранять группу общего каталога, sticky — защищать чужие файлы в общих каталогах вроде /tmp. Эти механизмы объясняют, как устроены многие системные команды и почему они требуют осторожности. Следующая тема переходит к перенаправлениям и конвейерам, где права проявляются при записи в файлы, и покажет, как системные процессы получают доступ к потокам ввода-вывода.

Литература

1. Ritchie D. M., Thompson K. The UNIX Time-Sharing System. — Communications of the ACM, 1974, Vol. 17, No. 7, С. 365–375, DOI: 10.1145/361011.361061.
2. Shotts W. The Linux Command Line: A Complete Introduction. 2nd ed. — No Starch Press, 2019. Открытая версия: https://linuxcommand.org/tlcl.php
3. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
4. The Linux man-pages project. — https://man7.org/linux/man-pages/
5. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
6. Free Software Foundation. GNU Coreutils Manual. — https://www.gnu.org/software/coreutils/manual/
7. Bauer M. Inspecting and Enforcing Linux Security with AppArmor. — Linux Journal, 2006.
8. Spencer R., et al. The Architecture of the Security-Enhanced Linux (SELinux) Kernel. — Proceedings of the 2003 USENIX Security Symposium, 2003.
9. Samar V., Schemers R. Unified Login with Pluggable Authentication Modules (PAM). — Open Software Foundation, 1995.

Дополнительные материалы

Вопросы для самопроверки

1. Какие сведения хранятся в каждом из семи полей строки /etc/passwd? Какое поле отвечает за хеш пароля и почему оно содержит x?
2. Почему файл /etc/shadow доступен только root и группе shadow, а /etc/passwd — всем пользователям?
3. Чем UID отличается от имени пользователя? Почему ядро проверяет права по числу, а не по имени?
4. Почему в Ubuntu администрирование выполняют через sudo, а не через вход под root?
5. Каков порядок проверки прав: владелец, группа, остальные? Что произойдёт, если владелец имеет меньше прав, чем группа?
6. Почему каталог с правом r, но без права x, позволяет получить список имён, но не позволяет прочитать атрибуты файлов?
7. Почему для удаления файла нужно право записи в каталог, а не в сам файл?
8. Переведите -rwxr-x--- в восьмеричную запись и обратно. Какое значение соответствует 644?
9. Какие права получит новый каталог при маске 027, и почему базовое значение для каталогов равно 777, а для файлов — 666?
10. Почему chmod 777 недопустим как решение проблемы «Permission denied»? Какие последствия он создаёт?
11. Что означает бит setgid на каталоге и почему новые файлы в нём получают группу каталога?
12. Зачем каталогу /tmp sticky bit, и какие файлы в нём может удалить пользователь?
13. Почему usermod -aG нужно использовать с ключом -a, и какой эффект даёт usermod -G без него?
14. Что показывает знак + в конце строки прав в выводе ls -l?
15. В чём принципиальное различие между дискреционным (DAC) и мандатным (MAC) контролем доступа? Почему суперпользователь root не может обойти ограничения политики MAC?
16. Как в SELinux работает модель Type Enforcement и почему процесс веб-сервера httpd_t не может прочитать файл базы данных postgresql_db_t даже при запуске от root?
17. Чем различаются режимы Enforce и Complain в AppArmor и в каких ситуациях применяется каждый из них?
18. Каковы четыре типа модулей в архитектуре PAM (auth, account, password, session) и как модуль pam_faillock защищает систему от брутфорс-атак?

Глоссарий темы

Шпаргалка

Команды, которые понадобятся в работе с правами и учётными записями:

id                       # UID, GID и группы текущего пользователя
id -nG                   # только имена групп
groups                   # группы текущего пользователя
grep '^имя:' /etc/passwd # строка учётной записи
grep '^группа:' /etc/group
ls -l файл               # права, владелец и группа
ls -ld каталог           # права самого каталога, а не его содержимого
stat -c '%a %A %n' файл  # восьмеричные и символьные права
chmod 750 файл           # задать права в восьмеричной записи
chmod u+x файл           # добавить право владельцу
chmod go-w файл          # убрать запись у группы и остальных
chmod +t каталог         # установить sticky bit
chmod 2775 каталог       # setgid и права rwxrwxr-x
chgrp группа файл        # сменить группу (в которую входит пользователь)
umask                    # текущая маска
umask -S                 # маска в символьной записи
find /usr/bin -perm -4000 -type f   # программы с setuid
sudo -n true             # проверка sudo без запроса пароля
sudo usermod -aG группа имя         # добавить в группу, не удаляя остальные
getfacl файл             # список ACL
setfacl -m u:имя:rwx каталог        # выдать права конкретному пользователю

Типичные ошибки

Ошибка 1. «Permission denied» при запуске скрипта ./script.sh. Симптом: сообщение bash: ./script.sh: Permission denied, при этом bash script.sh работает. Причина: у файла нет права x, и оболочка не может его запустить напрямую. Исправление: chmod u+x script.sh. Запуск через bash script.sh обходит проверку x, но скрипт при этом не становится исполняемым.

Ошибка 2. Файл открыт на чтение, но cat не работает. Симптом: cat dir/file.txt сообщает «Permission denied», хотя ls -l file.txt показывает r для всех. Причина: у каталога dir нет права x. Путь проходит через каталог, и на нём проверяется x. Исправление: chmod u+x dir. Право r файла не может заменить право x каталога.

Ошибка 3. ls -l показывает знаки вопроса вместо прав. Симптом: строка вида -????????? ? ? ? ?. Причина: у каталога есть право r, но нет x, поэтому атрибуты записей недоступны. Исправление: добавить право x каталогу командой chmod u+x каталог.

Ошибка 4. Файл не удаляется, хотя принадлежит пользователю. Симптом: rm файл сообщает «Permission denied», а ls -l показывает, что владелец — текущий пользователь. Причина: у каталога нет права записи, либо каталог имеет sticky bit и файл принадлежит другому пользователю. Исправление: проверить права каталога командой ls -ld каталог; для чужого файла в /tmp нужны права владельца файла или каталога.

Ошибка 5. Файлы, созданные командой sudo, нельзя редактировать. Симптом: echo текст >> файл сообщает «Permission denied», ls -l показывает владельца root. Причина: команда была выполнена с правами администратора, и файл создан от имени root. Исправление: sudo chown пользователь файл. Лучше не создавать пользовательские файлы через sudo.

Ошибка 6. chmod 777 «решает» проблему. Симптом: программа заработала, но файлы стали доступны всем пользователям системы, в том числе для записи. Причина: неверно назначенный владелец или группа, которые исправляются иначе. Исправление: вернуть права командой chmod 750 или подходящей, а владельца или группу назначить через chown и chgrp.

Ошибка 7. Пользователь потерял членство в группах после usermod. Симптом: после sudo usermod -G docker имя пользователь перестал получать доступ к группам sudo и adm. Причина: без ключа -a команда заменяет весь список дополнительных групп указанным. Исправление: sudo usermod -aG docker имя добавляет группу, не удаляя остальных; изменения вступают в силу при новом входе.

Ошибка 8. Файлы в общем каталоге принадлежат разным группам. Симптом: сотрудники не могут редактировать файлы друг друга, хотя все входят в одну группу. Причина: у каталога не установлен setgid, и новые файлы получают основную группу создавшего пользователя. Исправление: chmod g+s каталог или chmod 2775 каталог; уже созданные файлы переназначить chgrp -R группа каталог.

Ошибка 9. Скрипт сообщает об успехе, хотя данные не прочитаны. Симптом: echo $? выводит 0, а результат пустой или неверный. Причина: при ошибке перенаправления done < файл цикл while не выполняется, оболочка печатает сообщение об ошибке и продолжает работу, а код возврата скрипта берётся от последней команды (обычно echo), которая завершилась успешно. Исправление: проверять результат явно и использовать set -euo pipefail (подробно — в теме 15). Ошибки прав в таком случае заметны только по выводу, поэтому его всегда нужно читать.

Ошибка 10. umask «не работает» для уже созданного файла. Симптом: после umask 077 старые файлы остаются доступными для чтения. Причина: маска действует только на новые объекты; существующие файлы сохраняют свои права. Исправление: изменить права существующих файлов командой chmod.

Что почитать и посмотреть

• Shotts W. «The Linux Command Line», глава о правах и учётных записях (https://linuxcommand.org/tlcl.php) — пошаговое введение в права, владельцев и sudo для начинающих.
• Справочная страница passwd(5) и shadow(5) на man7.org (https://man7.org/linux/man-pages/) — точные форматы строк /etc/passwd, /etc/group и /etc/shadow.
• Справочная страница chmod(1) и umask(2) на man7.org — все формы записи прав и правила вычисления маски.
• GNU Coreutils Manual, раздел «File permissions» (https://www.gnu.org/software/coreutils/manual/) — описание chmod, chown, chgrp и stat с примерами.
• Nemeth E. и соавторы, «UNIX and Linux System Administration Handbook» — практика администрирования учётных записей и sudo; полезно для понимания, почему работа под root опасна.
• Kerrisk M., «The Linux Programming Interface» — подробное описание реальных и эффективных UID и GID, setuid и setgid на уровне системных вызовов.
• explainshell.com — вставьте строку вида chmod -R u+rwX dir и посмотрите разбор каждого ключа с описанием.
• OverTheWire Bandit (https://overthewire.org/wargames/bandit/) — игра на поиск паролей и файлов с нужными правами; уровни тренируют чтение ls -l и поиск файлов по владельцу.
• Википедия «Права доступа к файлам в Unix» — краткий обзор на русском языке для повторения; использовать как дополнение к справочным страницам.

Лабораторная работа 4. Права доступа в общем каталоге

• Раздел курса: тема 4 «Пользователи, группы и права доступа»

Введение

В теории темы 4 показано, что доступ к файлу определяется тремя классами пользователей и тремя видами прав, что смысл права x для каталога отличается от смысла права x для файла, что новые файлы получают права по маске umask, а специальные биты setuid, setgid и sticky меняют поведение программ и каталогов. В этой работе эти правила проверяются на практике. Сначала записывается ожидаемый результат, затем выполняется команда, результаты сравниваются и объясняется расхождение, если оно есть.

Работа состоит из основной (базовой) части (части 1–6) и продвинутой (углублённой, по желанию) части (часть 7). Все эксперименты выполняются в собственном каталоге ~/lab-04 без прав администратора. Команды, требующие root, отмечены явно: если на машине есть право sudo, их можно выполнить; иначе выполняется вариант без sudo через unshare -r или вывод делается по приведённому образцу.

Цель работы

Освоить чтение прав доступа по выводу ls -l, предсказывать и проверять доступ к файлам и каталогам, задавать права в символьной и восьмеричной записи, вычислять права новых файлов по umask и настраивать общий каталог группы.

После выполнения работы получится:

• читать строку прав -rwxr-x--- и переводить её в восьмеричную запись и обратно;
• предсказывать, какие операции над файлом и каталогом разрешены, если известны права каждого из них;
• объяснить ошибки «Permission denied» при отсутствии права x или r у каталога;
• вычислять права новых файлов и каталогов по значению маски umask;
• настроить общий каталог группы с битом setgid и защитить его sticky bit;
• найти и исправить ошибку прав в готовом сценарии, опираясь на сообщения системы.

Теоретический минимум

Необходимый материал изложен в теории темы 4: разделы «Права доступа к файлам и каталогам», «Числовая и символьная запись прав», «Специальные биты» и «Управление учётными записями». Команды работы:

Восьмеричная цифра складывается из значений r = 4, w = 2, x = 1. Цифра 7 означает rwx, 5 — r-x, 0 — отсутствие прав.

Перечень оснащения

• Ubuntu 22.04 или 24.04 (физическая или виртуальная машина либо WSL2).
• Архив окружения lr-env с генератором учебного сценария make-scenario.sh и файлом README.md.
• Пакет acl для части 7 (по желанию): sudo apt install acl.
• Права sudo нужны только для варианта А задания 5 части 5 (создание учётных записей). На машине без sudo выполняется вариант Б с командой unshare -r из пакета util-linux, который входит в базовую установку.

Порядок выполнения работы

Все эксперименты выполняйте в каталоге ~/lab-04. Создайте его и перейдите в него:

mkdir -p ~/lab-04
cd ~/lab-04

Перед каждой командой, меняющей права или проверяющей доступ, письменно запишите предсказание в таблицу вида «команда — ожидаемый результат — почему». После выполнения сравните результат с предсказанием. Расхождение не является ошибкой работы: его нужно объяснить в журнале работы, опираясь на таблицу прав из теории.

В журнал работы по каждой части входят предсказание, команды, выводы и объяснение. Части 1–6 базовые, часть 7 продвинутая.

Часть 1. Учётные записи и файлы их описания

Задание

1. Предскажите, какие поля будут в строке вашей учётной записи в /etc/passwd, и проверьте командой grep "^$(whoami):" /etc/passwd. Укажите, что означает поле пароля x и где хранится хеш.
2. Выведите строку вашей группы: grep "^$(id -gn):" /etc/group. Объясните, почему имени пользователя может не быть в списке членов его основной группы.
3. Выведите группы текущего пользователя командой id -nG. Для каждой группы из списка укажите, для чего она обычно нужна в Ubuntu.
4. Выполните ls -l /etc/passwd /etc/shadow и cat /etc/shadow. Объясните, почему чтение второго файла завершилось ошибкой, и почему хеши паролей вынесены в отдельный файл.

Что должно получиться

Строка учётной записи с объяснением каждого поля; ответы на вопросы пп. 2–4; вывод ls -l для двух файлов.

Часть 2. Права файла и права каталога

Задание

1. Создайте каталог и файл в нём:

   mkdir -p ~/lab-04/p2/dir
   echo "данные" > ~/lab-04/p2/dir/f.txt
   

2. Установите права каталога 400 (только чтение). Перед выполнением каждой команды ниже запишите предсказание и проверьте:

   chmod 400 ~/lab-04/p2/dir
   ls ~/lab-04/p2/dir
   ls -l ~/lab-04/p2/dir
   cat ~/lab-04/p2/dir/f.txt
   

   Обратите внимание: ls -l печатает знаки вопроса вместо атрибутов. Объясните, какое право отсутствует и почему.

3. Установите права 100 (только выполнение, без чтения). Проверьте по очереди ls, cat и cd:

   chmod 100 ~/lab-04/p2/dir
   ls ~/lab-04/p2/dir
   cat ~/lab-04/p2/dir/f.txt
   cd ~/lab-04/p2/dir && pwd
   

   Предскажите и объясните: почему cat с известным именем файла работает, а список имён недоступен.

4. Установите права 300 (запись и выполнение, без чтения). Проверьте, можно ли создать новый файл, и можно ли получить список:

   chmod 300 ~/lab-04/p2/dir
   touch ~/lab-04/p2/dir/new.txt
   ls ~/lab-04/p2/dir
   

5. Заполните таблицу: для каждой комбинации прав каталога (000, 400, 500, 300, 200, 100) отметьте, что выполнилось (ls, ls -l, cat файла по имени, cd, touch нового файла). Проверяйте каждую комбинацию, а не только предсказанную.

6. Верните каталог к правам 755 и объясните, почему удаление файла зависит от права записи в каталог, а не в файл.

Что должно получиться

Таблица из п. 5 с предсказаниями и результатами; объяснение трёх ошибок или «неожиданных успехов» (в частности, почему touch сработал при 300); ответ на п. 6.

Часть 3. Запись прав: символьная и восьмеричная

Задание

1. Создайте файл g и выполните цепочку изменений. Перед каждой строкой запишите ожидаемые права в восьмеричной и символьной записи:

   touch ~/lab-04/p3/g 2>/dev/null || (mkdir -p ~/lab-04/p3 && touch ~/lab-04/p3/g)
   cd ~/lab-04/p3
   chmod u=rwx,g=rx,o= g
   stat -c '%a %A %n' g
   chmod 640 g
   stat -c '%a %A %n' g
   chmod go+r g
   stat -c '%a %A %n' g
   chmod 0600 g
   stat -c '%a %A %n' g
   

2. Переведите в восьмеричную запись права rwxr-xr-- и r--r----- без помощи команды, а затем проверьте результат командой stat.

3. Найдите и объясните ошибку: нужно было выдать группе право записи в файл g, набрал chmod g=w,u+x g и получил неожиданный результат. Предскажите, какие права станут итоговыми, если исходные были 640, затем проверьте.

Что должно получиться

Таблица «команда — предсказание — результат» для п. 1; перевод из п. 2; объяснение ошибки в п. 3.

Часть 4. Маска umask и права новых файлов

Задание

1. Выведите текущую маску в двух формах:

   umask
   umask -S
   

2. Вычислите вручную права новых файлов и каталогов для масок 022, 027 и 077. Базовые значения: 666 для файлов и 777 для каталогов. В каждой цифре базового значения сбросьте биты, установленные в той же позиции маски (для этих трёх масок это совпадает с вычитанием). Отдельно рассчитайте маску 033 и объясните, почему вычитание дало бы неверный ответ.

3. Проверьте расчёт. Маску меняйте только в текущей оболочке и на время проверки:

   mkdir -p ~/lab-04/p4 && cd ~/lab-04/p4
   umask 027
   touch f027
   mkdir d027
   ls -l f027
   ls -ld d027
   umask 022
   

4. Установите маску 077, создайте файл и каталог, проверьте результат, верните 022. Объясните, почему после маски 077 другой пользователь не сможет читать ваши файлы.

5. Объясните, почему umask не добавляет право x файлам. Предскажите права файла, созданного командой touch при маске 000, и проверьте.

Что должно получиться

Расчёт трёх масок в таблице «маска — файлы — каталоги»; вывод команд п. 3 и п. 4; ответ на вопрос п. 5.

Часть 5. Общий каталог группы: setgid и sticky

Задание

Смоделируйте общий каталог отдела. Группа выбирается из тех, в которые входит ваш пользователь (id -nG); в примере используется группа adm, в которую входит учебная учётная запись student. Замените название на свою группу.

1. Создайте каталог, назначьте группу и установите права 2775:

   mkdir -p ~/lab-04/share
   chgrp adm ~/lab-04/share
   chmod 2775 ~/lab-04/share
   ls -ld ~/lab-04/share
   

   Объясните, какая цифра в 2775 включает setgid, и где в строке прав это видно.

2. Создайте файл в этом каталоге и проверьте его группу: touch ~/lab-04/share/report.txt && ls -l ~/lab-04/share. Предскажите группу файла до выполнения команды и объясните совпадение или расхождение с предсказанием.

3. Установите sticky bit на каталог: chmod +t ~/lab-04/share, затем проверьте stat -c '%a %A %n' ~/lab-04/share. Объясните разницу между t и T в строке прав.

4. Проверьте общий каталог с несколькими учётными записями. Выполните один из двух вариантов.

   Вариант А (есть sudo). Создайте группу отдела и двух пользователей, выдайте им общий каталог вне домашнего каталога и проверьте, что второй пользователь не может удалить файл первого:

   sudo groupadd otdel
   sudo useradd -m -s /bin/bash -G otdel anna
   sudo useradd -m -s /bin/bash -G otdel boris
   sudo mkdir /srv/otdel
   sudo chgrp otdel /srv/otdel
   sudo chmod 3775 /srv/otdel
   sudo -u anna touch /srv/otdel/plan.txt
   ls -l /srv/otdel
   sudo -u boris rm -f /srv/otdel/plan.txt
   

   Предскажите группу файла plan.txt и результат последней команды (ожидается отказ «Operation not permitted» из-за sticky bit). После проверки удалите учебные записи: sudo userdel -r anna, sudo userdel -r boris, sudo groupdel otdel, sudo rm -rf /srv/otdel.

   Вариант Б (без sudo). Команда unshare -r запускает оболочку в отдельном пространстве имён пользователей, где текущий пользователь отображается как root (UID 0), но реальных привилегий не получает. Выполните:

   cd ~/lab-04
   unshare -r bash -c 'id; ls -ln share; cat /etc/shadow; chown 1001 share/report.txt'
   

   Пример вывода:

   uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
   total 0
   -rw-r--r-- 1 0 0 0 Oct 13 01:51 report.txt
   cat: /etc/shadow: Permission denied
   chown: changing ownership of 'share/report.txt': Invalid argument
   

   Объясните, почему «root» внутри пространства имён видит свои файлы с владельцем 0, но не может прочитать /etc/shadow и передать файл другому UID. Сделайте вывод о том, что ядро проверяет реальные идентификаторы, а не имя root. Если команда завершается ошибкой Operation not permitted (в некоторых установках Ubuntu 24.04 непривилегированные пространства имён ограничены AppArmor), опишите в журнале работы поведение варианта А по образцу из теории.

5. Смоделируйте ситуацию, при которой в общем каталоге все должны работать с файлами, но удалять чужие файлы нельзя. Укажите, какой режим (восьмеричный) нужен и почему. Не применяйте 777.

Что должно получиться

Вывод ls -ld и ls -l из пп. 1–2; объяснение setgid; вывод и объяснение выбранного варианта п. 5; восьмеричное значение режима из п. 6 с обоснованием.

Часть 6. Найти и исправить ошибку «Permission denied»

Эта часть проверяет умение читать сообщения системы и исправлять права, не угадывая. Команда создаёт учебный сценарий с двумя ошибками прав. Архив окружения должен быть распакован, а сценарий запущен через bash:

unzip ~/Downloads/lr-env.zip -d ~/lab-04 && cd ~/lab-04/lr-env
bash make-scenario.sh
cd ~/lab-04/report-project

Содержимое генератора до диагностики не читается. Задача состоит в том, чтобы найти ошибки по сообщениям и выводу ls -l, исправить их минимальным изменением прав и объяснить каждое исправление.

Задание

1. Запустите скрипт сводки и предскажите результат:

   ./report.sh
   

   Пример вывода на учебной машине:

   bash: ./report.sh: Permission denied
   

   Объясните, почему сообщение появилось, даже если содержимое скрипта правильное. Выполните ls -l report.sh и укажите, какого права не хватает.

2. Запустите тот же скрипт через интерпретатор и сравните результат:

   bash report.sh
   echo "код возврата: $?"
   

   Пример вывода:

   report.sh: line 9: data/sales.csv: Permission denied
   итого: 0
   код возврата: 0
   

   Оболочка напечатала сообщение об ошибке, но скрипт продолжил работу и завершился с кодом 0. Объясните, почему код возврата не отражает ошибку, хотя файл data/sales.csv не прочитан. Какой фрагмент скрипта должен был остановить работу?

3. Найдите вторую ошибку. Проверьте каталог data командами ls -ld data и ls -l data, а также чтение файла cat data/sales.csv. Определите, какое право отсутствует у каталога, и объясните, почему cat завершился ошибкой при наличии права r на сам файл.

4. Исправьте обе ошибки минимальным изменением прав. Не используйте chmod 777 и не меняйте владельца. Перед исправлением запишите, какие права нужны скрипту (x на сам скрипт, x на каталог data, r на файл) и почему именно они.

5. Повторите запуск ./report.sh и проверьте файл summary.txt. Ожидаемый итог: total=450.

6. Найдите ошибку в самом скрипте: он завершился с кодом 0 при неудачном чтении данных. Предложите правку в стиле set -euo pipefail и объясните, почему она не решает проблему прав, но делает ошибку заметной. Правку не вносите в файл, а опишите в журнале работы (до темы 15 достаточно понимания идеи).

Что должно получиться

В журнале работы четыре пункта: сообщения об ошибках с объяснением, список исправлений с командами chmod, итоговый вывод total=450, описание правки скрипта для подавления тихого сбоя. Исправлять «по наитию» без предсказания не следует: каждое изменение прав должно иметь объяснение.

Часть 7 (продвинутая). Списки ACL и поиск setuid

Задание

1. Найдите все программы с битом setuid в системе и выберите одну из них для анализа: find /usr/bin -perm -4000 -type f 2>/dev/null. Для выбранной программы выведите ls -l и объясните, почему программе нужен setuid. Укажите, какой файл она меняет или читает.
2. Установите пакет acl (при наличии sudo) и создайте каталог с правами, которые не выражаются стандартными классами: setfacl -m u:имя:rwx каталог. Имя пользователя возьмите другое, чем ваше, например nobody (если такого пользователя нет в системе, используйте другого существующего). Проверьте getfacl каталог.
3. Найдите признак ACL в выводе ls -l (знак + в конце строки прав) и объясните, почему chmod меняет маску ACL. Ответьте на вопрос, почему ACL полезнее групп, когда доступ нужен одному пользователю из другого отдела.

Что должно получиться

Вывод ls -l для выбранной программы с объяснением; вывод getfacl; короткий ответ на п. 3.

Журнал работы

Для себя ведите записи в порядке «предсказание — команда — фактический вывод — объяснение расхождения». Выводы команд сохраняйте полностью, а не пересказывайте. В конце отметьте, что оказалось неожиданным и как вы это проверили.

Контрольные вопросы

1. Почему в /etc/passwd поле пароля содержит x, а хеш хранится в /etc/shadow? Кто может читать второй файл?
2. Какие поля содержит строка /etc/passwd? Что означает UID 0 и почему ядро распознаёт root по числу?
3. Пользователь является владельцем файла с правами -r--rwxrwx. Может ли он прочитать файл? Объясните порядок проверки классов.
4. Почему каталог с правами r-- не позволяет открыть файлы внутри него командой cat, хотя список имён видим?
5. Почему для удаления файла нужно право записи в каталог, а не в сам файл? Как sticky bit меняет это правило?
6. Переведите -rwxr-x--- в восьмеричную запись и обратно: 640 в символьную запись.
7. Маска umask равна 027. Какие права получат новый файл и новый каталог? Выполните расчёт, а затем проверку.
8. Почему chmod 777 не является решением проблемы «Permission denied» и какой вред он создаёт?
9. Почему chgrp разрешён владельцу только для групп, в которые он входит? Какая защита за этим стоит?
10. Как по выводу ls -l отличить setuid от setgid и от sticky bit? Что означают заглавные S и T?
11. Почему usermod -G без ключа -a опасен для администратора? Какой эффект он даёт?
12. Скрипт завершился с кодом 0, хотя не прочитал входные данные. Почему код возврата не сообщил об ошибке, и какая дисциплина (например, set -e) решает эту проблему?