Права доступа и аккуратное повышение полномочий

Вы создали скрипт, но команда отвечает «Permission denied». Другая программа не может прочитать настройки, хотя вы сами открываете файл. В обеих ситуациях нужно определить пользователя процесса, права файла и права каталогов пути. Команда chmod 777 выдаёт лишние полномочия и может скрыть причину, не решив её правильно.

Мы уже умеем выбирать файлы и проверять коды завершения. Теперь используем эти навыки, чтобы увидеть отказ и объяснить его. Практика выполняется обычным пользователем в своей новой папке. Времени потребуется примерно двадцать пять минут; изменения системных разрешений не нужны.

Владелец, группа и остальные

lab_dir=$(mktemp -d)
cd "$lab_dir"
printf 'private note\n' > note.txt
id
ls -l note.txt

Строка ls показывает тип объекта, разрешения, владельца и группу. Обычный файл часто начинается с -, каталог — с d, ссылка — с l. Три группы rwx относятся к владельцу, группе и остальным. Это базовая Unix-модель; ACL и дополнительные политики могут расширять её. В учебной Ubuntu рассмотрим обычные файлы без специальных правил.

Для файла r разрешает чтение, w — изменение содержимого, x — исполнение. У каталога смысл другой: r позволяет перечислять имена, x — проходить по пути и обращаться к объектам, w вместе с нужными правами позволяет менять записи каталога. Поэтому удаление файла зависит прежде всего от каталога, а не от его собственного бита записи.

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

Минимальная необходимая настройка

chmod u=rw,go= note.txt
ls -l note.txt
cat note.txt
chmod u-w note.txt
printf 'changed\n' > note.txt

Первый режим даёт владельцу чтение и запись, группе и остальным — ничего. После снятия записи последний вызов должен получить отказ у обычного пользователя. Не запускайте этот опыт как root: привилегированный процесс может обходить обычные ограничения. Сообщение зависит от shell, а исходный текст должен сохраниться.

Восстановите свой бит записи: chmod u+w note.txt. Числовой режим 600 означает то же базовое распределение rw для владельца и отсутствие прав у остальных. В одной тройке r=4, w=2, x=1, поэтому rw=6, rx=5. Это запись битов, а не уровень «силы защиты».

Для собственного каталога часто разумен 700, для исполняемого файла с общедоступным чтением —755. Но рецепт выбирается по назначению: конфигурация с секретом не обязана быть читаемой всеми. Символическая форма показывает намерение, например u+x; числовая устанавливает полный набор обычных битов.

Маска новых объектов

umask определяет, какие биты не выдаются при создании обычных файлов и каталогов. Она не меняет ранее созданные объекты и не является арифметическим вычитанием из любого произвольного режима. Посмотрим отдельный дочерний shell:

bash -c 'umask 077; printf "hello\n" > private.txt; mkdir private-dir'
ls -ld private.txt private-dir

При обычных начальных режимах ожидаются 600 и 700. Файлы не получают execute автоматически от того, что маска его разрешает: приложение выбирает запрошенный режим. Маска дочерней оболочки не изменяет настройку родительской. Поэтому опыт не меняет поведение всех ваших последующих сеансов.

Sudo не заменяет диагностику

Sudo запускает определённую команду с полномочиями, предусмотренными политикой. При запросе пароля обычно нужен пароль текущего пользователя, а символы не показываются. В managed Ubuntu политика может запретить команду. Это не повод искать способ её обхода.

Повышение прав оправдано для установки известных системных пакетов в учебной VM. Для собственного отчёта или скрипта сначала проверьте путь, владельца и режим. Если вы выполнили редактор через sudo и оставили root-owned файл, повторное sudo лишь поддерживает неверный рабочий процесс. Не запускайте постоянный root-shell для всего курса.

Есть тонкость перенаправления: в sudo command > file файл открывает ваша текущая оболочка, до запуска привилегированной программы. Поэтому sudo не обязательно даст право перенаправлению. Здесь не будем записывать системную конфигурацию таким способом; позже предпочтем пользовательский сервис и явно ограниченные операции.

Самостоятельная лаборатория

Создайте заметку, которую может читать только владелец, и каталог, куда может заходить только владелец. Снимите у своей заметки право записи, получите отказ, затем верните его. Отдельно создайте каталог без x и покажите, почему обращение к файлу внутри не проходит; после опыта восстановите владельцу rwx.

Критерии готовности: права изменены только на ваших объектах, содержимое не потеряно, вы можете объяснить каждый бит. Выполнение через root не засчитывает проверку отказа. Если вывод показывает знак дополнительных ACL, назовите это ограничением опыта и сверяйте реальное решение с политикой среды.

Разбор

Режим 600 не мешает владельцу читать заметку, но обычные другие пользователи не получают чтение через эти биты. Каталог 700 ограничивает проход. Отказ изменения воспроизводится снятием u-w, а возврат u+w восстанавливает требуемую работу. Нельзя делать вывод об абсолютной конфиденциальности: root, резервные копии и уже скопированные данные имеют отдельные границы. Следующий шаг — посмотреть, как пользователя и ресурсы наследуют процессы.

Первичные источники: GNU Coreutils: setting permissions, chmod, Linux path resolution.