Файлы и права в Linux: как устроены пути и доступ

На сервере приходится постоянно отвечать на одни и те же вопросы: где лежит нужный файл, кто может его изменить и почему одна команда работает, а другая получает Permission denied. Чтобы не угадывать, достаточно понять пути и три набора прав — для владельца, группы и остальных пользователей.

Все упражнения ниже выполняются от обычного пользователя в его домашнем каталоге. Они не затрагивают /etc, /var и другие системные каталоги. $HOME означает домашний каталог текущего пользователя, например /home/alex.

Чем файл отличается от каталога

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

Например, в пути /etc/nginx/nginx.conf:

• / — начало дерева;
• etc и nginx — каталоги;
• nginx.conf — имя файла.

Кроме содержимого, у каждого объекта есть служебные сведения: владелец, группа, права, размер и время изменения. Команды ls и stat позволяют их увидеть.

Как Linux находит файл по пути

Путь, начинающийся с /, называется абсолютным: он ведёт от корня файловой системы и не зависит от текущего каталога. Путь notes.txt называется относительным: командная оболочка ищет его там, где вы сейчас находитесь.

Следующие команды только показывают текущее место. Выполните их в терминале под обычным пользователем:

pwd
realpath .

pwd печатает текущий каталог. Точка в realpath . означает «текущий каталог», а realpath превращает это обозначение в полный путь. Обычно обе команды покажут одно и то же, например /home/alex.

Ещё два обозначения встречаются постоянно: .. ведёт в родительский каталог, а $HOME — в домашний. Перед копированием или удалением полезно вывести полный путь через realpath: так легче заметить, что команда направлена не туда.

Создадим каталог для упражнений

Чтобы попробовать команды без риска для системных файлов, создадим небольшую структуру внутри $HOME. Блок создаёт два каталога и текстовый файл:

mkdir -p "$HOME/linux-files-lab/source"
mkdir -p "$HOME/linux-files-lab/backup"
printf 'version 1\n' > "$HOME/linux-files-lab/source/app.conf"

mkdir создаёт каталог. Ключ -p также создаёт недостающие родительские каталоги и не считает ошибкой уже существующий путь. Команда printf выводит строку version 1, а знак > направляет её в файл app.conf.

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

Как посмотреть содержимое и свойства файла

Теперь посмотрим созданную структуру и убедимся, что работаем с ожидаемым файлом. Команды ничего не меняют; в результате должны быть видны каталоги source, backup и строка version 1:

ls -la "$HOME/linux-files-lab"
ls -l "$HOME/linux-files-lab/source/app.conf"
cat "$HOME/linux-files-lab/source/app.conf"
stat "$HOME/linux-files-lab/source/app.conf"

Первая команда показывает содержимое каталога. У ls ключ -l добавляет права, владельца, размер и время изменения, а -a включает скрытые имена, начинающиеся с точки. Вторая команда выводит сведения только о файле app.conf.

cat печатает содержимое; ожидается одна строка version 1. stat показывает более подробные служебные сведения. Пока достаточно найти поля Size, Access и строки с именами владельца и группы. Если команда сообщает No such file or directory, сравните путь с тем, который создали в предыдущем разделе.

Как копировать и проверять файл

Команда cp получает сначала источник, затем место для копии. Здесь мы копируем app.conf в каталог backup и после этого сравниваем два файла:

cp -i "$HOME/linux-files-lab/source/app.conf" \
  "$HOME/linux-files-lab/backup/app.conf"
cmp "$HOME/linux-files-lab/source/app.conf" \
  "$HOME/linux-files-lab/backup/app.conf"

Ключ -i просит подтверждение, если файл назначения уже существует. Это полезно при ручной работе, хотя в автоматическом сценарии нужны другие проверки. cmp сравнивает файлы байт за байтом и ничего не печатает, когда они совпадают.

Сразу после cmp можно выполнить echo $?. Ноль означает, что сравнение прошло успешно. Единица означает различие, другое ненулевое значение — ошибку, например отсутствие файла или запрет чтения.

Кто владеет файлом

Linux связывает каждый процесс и файл с числовыми идентификаторами пользователя и группы. UID — номер пользователя, GID — номер группы. Имена вроде alex или www-data нужны людям; при проверке доступа система использует именно номера.

Этот блок показывает текущего пользователя, его группы, а затем владельца и права созданного файла. Обе команды только читают сведения системы:

id
stat -c '%U:%G %A %a %n' "$HOME/linux-files-lab/source/app.conf"

Типичный вывод id выглядит так:

uid=1000(alex) gid=1000(alex) groups=1000(alex),27(sudo)

uid=1000(alex) — номер и имя пользователя. gid=1000(alex) — его основная группа. После groups= перечислены все группы текущего процесса. Членство в группе sudo означает возможность запросить административные права, но обычные команды по-прежнему выполняются как alex.

Во второй команде stat -c задаёт короткий формат: %U — владелец, %G — группа, %A — права буквами, %a — права числом, %n — путь. Для созданного файла вы увидите примерно такую строку:

alex:alex -rw-r--r-- 644 /home/alex/linux-files-lab/source/app.conf

Как читать строку прав

Фрагмент -rw-r--r-- из предыдущего вывода состоит из типа объекта и трёх групп прав. Схема ниже не является командой; она показывает назначение каждой части строки:

-   rw-   r--   r--
│    │     │     └─ остальные пользователи
│    │     └─────── группа файла
│    └───────────── владелец
└────────────────── обычный файл

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

Число 644 описывает те же права: владелец может читать и изменять файл, группа и остальные — только читать. Режим 755 для каталога разрешает владельцу менять его содержимое, а остальным — просматривать имена и проходить внутрь.

Как изменить права через chmod

В упражнении явно зададим обычный режим для файла и каталога. Команды меняют только объекты внутри $HOME/linux-files-lab:

chmod u=rw,go=r "$HOME/linux-files-lab/source/app.conf"
chmod u=rwx,go=rx "$HOME/linux-files-lab/source"
stat -c '%A %a %n' \
  "$HOME/linux-files-lab/source/app.conf" \
  "$HOME/linux-files-lab/source"

В записи u=rw,go=r буква u обозначает владельца, g — группу, o — остальных. Знак = заменяет их текущие права указанным набором. Для каталога владельцу назначены rwx, группе и остальным — rx.

Последняя команда должна показать режим 644 у файла и 755 у каталога. Не применяйте эти числа ко всему подряд: файл с паролем должен быть закрыт строже, а программе может понадобиться право выполнения.

Почему новые файлы сразу получают определённые права

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

umask

Частый результат — 0022. Это не готовый режим, а права, которые нужно убрать из начального набора. Обычный файл создаётся максимум с 666, каталог — с 777; после маски 0022 обычно получаются 644 и 755.

umask не меняет существующие файлы. Кроме того, программа может сама запросить более строгие права — например, SSH закрывает приватные ключи независимо от общего ожидания.

Почему файл иногда удаляется без права записи в него

Имя файла хранится в родительском каталоге. Поэтому удаление меняет каталог, а не содержимое файла. Пользователь может удалить файл только тогда, когда у него есть подходящие права на родительский каталог и возможность пройти по всему пути.

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

Как разобраться с Permission denied

Сообщение Permission denied говорит только о запрете операции. Оно не указывает, какой элемент пути помешал. Команда namei раскладывает путь на части и показывает права каждой части:

namei -l "$HOME/linux-files-lab/source/app.conf"

Ключ -l добавляет к каждому компоненту тип, права, владельца и группу. Начинайте читать сверху. Для каждого каталога пользователю нужен проход — буква x в подходящей тройке прав. Для самого файла при чтении нужна r.

Если отказ получает служба, важно проверить доступ от имени её пользователя, а не от root. Для Nginx этот разбор продолжен в статье о правах файлов сайта. Команда chmod -R 777 не является диагностикой: она открывает лишний доступ и скрывает место настоящей ошибки.

Как удалить файлы упражнения

Перед удалением выведите точный путь и список объектов. Эти две команды ничего не удаляют:

realpath "$HOME/linux-files-lab"
find "$HOME/linux-files-lab" -maxdepth 3 -print

realpath должен показать каталог внутри вашего $HOME. У find первый аргумент задаёт начало поиска, -maxdepth 3 ограничивает глубину, -print выводит найденные пути. В списке должны быть только созданные в этой статье каталоги и два файла app.conf.

Если список верен, удалите учебный каталог интерактивно:

rm -ri -- "$HOME/linux-files-lab"

rm -r удаляет каталог вместе с содержимым, -i спрашивает подтверждение, а -- завершает список параметров. Читайте каждый вопрос. Если путь отличается от ожидаемого, ответьте n и остановитесь.

После этой статьи вы должны уметь объяснить путь к файлу, найти его владельца, прочитать режим 644 или 755 и определить, на каком каталоге возникает запрет. Следующая практическая тема — права файлов сайта для Nginx — применяет эту модель к реальной службе.

Первоисточники

• GNU Coreutils: file permissions
• GNU Coreutils: symbolic modes
• GNU Coreutils: stat
• GNU Coreutils: cp