Права доступа: почему permission denied

Как читать rwx, что означают цифры и почему каталогу нужен бит x.

Как читать вывод ls -l

-rw-r--r--  1 deploy  app   1240 Jul 24 10:12 app.conf
drwxr-xr-x  2 deploy  app   4096 Jul 24 10:12 config

Первый символ — тип: - файл, d каталог, l символическая ссылка. Дальше три группы по три бита:

• символы 2–4 — права владельца
• символы 5–7 — права группы
• символы 8–10 — права остальных

В каждой группе: r чтение, w запись, x выполнение.

Цифры

Каждый бит — степень двойки: r = 4, w = 2, x = 1. Сумма даёт цифру:

Отсюда 644 (владелец пишет, остальные читают) и 755 (плюс выполнение для всех).

Главная ловушка: x у каталога

У файла x означает «можно запустить». У каталога x означает «можно войти внутрь» — то есть обратиться к чему-то по пути через этот каталог.

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

chmod 644 /opt/app        # каталог без x
cat /opt/app/config.yml   # Permission denied, хотя у файла 644

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

Владелец и группа

chown deploy:app file      # сменить владельца и группу
chmod 640 file             # владелец rw, группа r, остальные ничего
chmod -R u+rwX,go-w dir    # рекурсивно

Заглавная X в последней команде — полезный приём: она ставит бит выполнения только каталогам и тем файлам, у которых он уже был. Обычная x сделала бы исполняемыми все файлы подряд.

Что смотреть при ошибке

1. ls -l на сам файл — права и владелец.
2. namei -l /полный/путь — покажет права на каждый каталог по пути. Обычно проблема здесь.
3. id — от кого вы работаете и в каких группах состоите. Членство в группе применяется при входе в систему: после usermod -aG нужно перелогиниться.

Если всё выглядит правильно

Значит, дело не в правах. Дальше смотрят SELinux или AppArmor (getenforce, aa-status) — они могут запретить доступ поверх обычных прав, и в логах это выглядит так же.