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

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

Пользователь — это учётная запись с числовым идентификатором (UID). Пользователи — это люди, но также и сервисы: nginx в Ubuntu обычно работает от www-data (в RHEL — от nginx), PostgreSQL — от postgres. Группа — это именованный набор пользователей, который позволяет выдать нескольким пользователям одинаковый доступ. root (UID 0) может всё и обходит обычные проверки прав, поэтому повседневно работать под root не стоит. Учётные записи перечислены в /etc/passwd, хэши паролей — в /etc/shadow (читать может только root), группы — в /etc/group. Команда id показывает, кто вы и в каких группах состоите.

1whoami                       # current user
2id                           # uid, gid and all groups
3id www-data                  # who is the web server user?
4getent passwd your_user      # account details
5groups your_user             # group membership
6sudo adduser your_user       # create a user (Debian/Ubuntu, interactive)
7sudo useradd -m -s /bin/bash your_user   # portable, non-interactive
8sudo usermod -aG www-data your_user      # ADD to a group (-a matters!)

02Как читать rwx и восьмеричные права

Выполните ls -l, и вы увидите что-то вроде -rw-r--r-- 1 deploy www-data. Первый символ — тип (- файл, d каталог, l ссылка). Затем идут три тройки: права владельца, права группы и права всех остальных. r — чтение, w — запись, x — выполнение. Для каталога смысл смещается: r позволяет выводить список имён, w — создавать и удалять файлы внутри, а x — входить в каталог и обращаться к файлам по пути. Каждая тройка — это ещё и число: r = 4, w = 2, x = 1, которые складываются. Так, 644 — это rw-r--r-- (владелец пишет, остальные читают), 755 — rwxr-xr-x, 600 — доступ только владельцу, а 640 позволяет группе читать.

• 644: обычные файлы. 755: каталоги и скрипты. 600: секреты вроде SSH-ключей и файлов .env.
• 640 / 750: у владельца полный доступ, у группы только чтение, у остальных ничего; хорошо подходит для конфигов приложения, общих с группой веб-сервера.
• 777 означает, что писать может кто угодно в системе. Это прячет реальную проблему и открывает дыру в безопасности.
• Специальные биты: setgid на каталоге (2775) заставляет новые файлы наследовать группу каталога; sticky bit (1777, как на /tmp) не даёт пользователям удалять чужие файлы.

03chmod, chown и исправление владельцев

chmod меняет права, chown — владельца и группу. Обе команды принимают -R для рекурсивных изменений, и это мощно и опасно: неосторожный chmod -R не на том каталоге может сломать SSH или всю систему. Используйте символьную запись для небольших точных изменений (u+x добавляет владельцу право на выполнение, g-w убирает у группы право на запись) и восьмеричную, когда нужен точный результат. Частый приём — выставлять файлам и каталогам разные права через find, потому что каталогам нужен x, а обычным файлам он, как правило, не нужен.

1chmod 600 ~/.ssh/id_ed25519          # private key: owner only
2chmod u+x deploy.sh                   # make a script executable
3chmod g-w config.php                  # remove group write
4sudo chown deploy:www-data -R /var/www/app
5# Directories 755, files 644, in one tree
6find /var/www/app -type d -exec chmod 755 {} +
7find /var/www/app -type f -exec chmod 644 {} +
8# Inspect a path permission by permission
9namei -l /var/www/app/storage/logs/app.log

04sudo и /etc/sudoers

sudo выполняет одну команду от имени root (или другого пользователя), предварительно проверив, что вам это разрешено. Каждый вызов логируется, что для подотчётности гораздо лучше, чем общий пароль root. В Ubuntu участники группы sudo получают полные права sudo; в RHEL эта группа называется wheel. Правила лежат в /etc/sudoers и в файлах в /etc/sudoers.d. Никогда не редактируйте их обычным редактором: используйте visudo, который проверяет синтаксис перед сохранением. Сломанный файл sudoers может лишить sudo всех сразу. Можно также выдавать узкие права, например разрешить пользователю deploy перезапускать один сервис без пароля — и больше ничего. В свежих релизах Ubuntu поставляется sudo-rs — переписанная с безопасной работой с памятью версия с теми же командами и конфигом.

1sudo usermod -aG sudo your_user     # full sudo (wheel on RHEL)
2sudo -l                             # what am I allowed to run?
3sudo -u postgres psql               # run as another user
4sudo visudo -f /etc/sudoers.d/deploy
5# Content of /etc/sudoers.d/deploy:
6deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp.service

05umask, сервисные пользователи и ACL

umask определяет права новых файлов по умолчанию, убирая биты. Распространённое значение 022 даёт новым файлам 644, а новым каталогам 755; umask 002 даёт 664 и 775, что подходит командам, работающим через общую группу. Для приложений создавайте отдельного системного пользователя без login shell и делайте его владельцем только того, во что приложение должно писать. ACL (списки контроля доступа) добавляют дополнительные правила поверх модели владелец/группа/остальные, например дают ещё одному пользователю право записи в один каталог. Они удобны, но не видны при беглом ls -l (ищите + в конце строки прав), поэтому используйте их умеренно и документируйте.

1umask                                   # show current mask, e.g. 0022
2sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
3sudo chown -R myapp:myapp /var/lib/myapp
4# ACL: let www-data write to one directory, now and for new files
5sudo setfacl -R -m u:www-data:rwX /var/www/app/storage
6sudo setfacl -R -d -m u:www-data:rwX /var/www/app/storage
7getfacl /var/www/app/storage

06Классический баг: веб-сервер не может писать

Типичная ситуация: PHP- или Node-приложение работает локально, а в продакшене пишет в лог «Permission denied», когда пытается записать кэш, логи или загрузки. Причина почти всегда в том, что код задеплоил один пользователь (deploy или root), а приложение работает от другого (www-data или пользователя пула PHP-FPM). Решение — не 777. Вместо этого выясните, от какого пользователя работает процесс, оставьте код во владении пользователя deploy и доступным приложению только для чтения, а право записи дайте только тем каталогам, которым оно действительно нужно, например storage и bootstrap/cache в Laravel. Бит setgid сохраняет за новыми файлами правильную группу. И помните: деплой или запуск artisan-команд под root может создать файлы кэша во владении root, которые приложение потом не сможет перезаписать.

1ps -o user,pid,cmd -C php-fpm8.3     # which user runs PHP? (adjust version)
2ps -o user,pid,cmd -C node
3cd /var/www/app
4sudo chown -R deploy:www-data .
5sudo chmod -R 750 .
6sudo chmod -R 2775 storage bootstrap/cache     # group write + setgid
7sudo find storage bootstrap/cache -type f -exec chmod 664 {} +
8sudo -u www-data php artisan cache:clear       # run as the app user, not root

07Как ядро на самом деле проверяет доступ

При каждом open ядро сравнивает effective UID процесса и его группы (основную и дополнительные) с владельцем и группой файла. Проверка выбирает ровно один класс по порядку: если вы владелец, учитываются только биты владельца; иначе, если совпадает одна из ваших групп, только биты группы; иначе — биты остальных. Классы не складываются, поэтому файл с правами 0077 запрещает доступ собственному владельцу, хотя все остальные могут его читать. Чтобы добраться до файла, нужно также право x (поиск) на каждом каталоге пути, что namei -l показывает с первого взгляда. Удаление или переименование файла зависит от права записи на каталог, а не на файл. Root обходит большинство этих проверок не магией, а через capabilities, такие как CAP_DAC_OVERRIDE, а работающий процесс сохраняет список групп, который был у него при входе, поэтому новое членство в группе требует новой сессии.

1cat /proc/self/status | grep -E '^(Uid|Gid|Groups)'   # real/effective IDs
2chmod 077 test.txt && cat test.txt      # owner denied: only owner bits apply
3namei -l /srv/app/shared/.env           # x needed on every directory
4sudo -u www-data test -r /srv/app/shared/.env && echo readable
5newgrp www-data                          # pick up a new group without relogin

08setuid, setgid и capabilities

Программа с setuid работает с привилегиями своего владельца, а не вызывающего; passwd и sudo имеют setuid root, чтобы обычные пользователи могли контролируемо менять защищённые файлы. Каждый setuid-root бинарник — это поверхность атаки, поэтому проводите их аудит и никогда не ставьте этот бит на скрипты или собственные утилиты. Linux capabilities делят власть root примерно на сорок частей, так что программа может получить только одну: cap_net_bind_service позволяет процессу без root слушать порты ниже 1024, cap_net_raw позволяет ping отправлять raw-пакеты. Файловые capabilities задаются через setcap, а systemd может выдать их сервису через AmbientCapabilities, отбросив всё остальное через CapabilityBoundingSet. Файловые системы также можно монтировать с nosuid, nodev и noexec — дешёвый шаг харденинга для каталогов загрузок и временных файлов, где никогда не должно быть исполняемых программ.

1find / -xdev -perm -4000 -type f 2>/dev/null   # setuid binaries
2getcap -r /usr/bin 2>/dev/null                 # files with capabilities
3sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/myserver
4# In a systemd unit, instead of setcap:
5#   AmbientCapabilities=CAP_NET_BIND_SERVICE
6#   CapabilityBoundingSet=CAP_NET_BIND_SERVICE
7findmnt -o TARGET,OPTIONS /tmp                  # check nosuid,noexec

09Когда права верные, а доступ всё равно запрещён

Если ls -l выглядит идеально, а приложение всё равно получает EACCES, «нет» говорит что-то поверх классической модели. Обычный подозреваемый — mandatory access control: AppArmor в Ubuntu ограничивает программы путями из их профиля, а SELinux в RHEL помечает каждый файл и процесс метками и запрещает всё, что не разрешено политикой, независимо от владельца и прав. В SELinux файл, перемещённый (а не скопированный) в web root, сохраняет старую метку — классическая причина ошибок 403; restorecon это исправляет. Другие скрытые слои: атрибут immutable, установленный через chattr +i, который блокирует даже root, пока его не снимут; монтирование read-only или noexec; маски ACL, ограничивающие записи групп; и в контейнерах — user namespaces, отображающие root контейнера на непривилегированный UID хоста. Проверьте всё это, прежде чем трогать права.

1sudo aa-status                        # AppArmor profiles in enforce mode
2sudo journalctl -k | grep -i apparmor  # AppArmor denials
3ls -Z /var/www/html                    # SELinux labels (RHEL family)
4sudo ausearch -m avc -ts recent        # SELinux denials
5sudo restorecon -Rv /var/www/html      # reset labels to policy defaults
6lsattr /etc/resolv.conf                # 'i' = immutable
7getfacl /srv/app/storage | grep mask   # ACL mask limiting entries

10UID в контейнерах и томах

Ядро хранит числа, а не имена. Файл, принадлежащий UID 1000, принадлежит тому, у кого UID 1000 в текущей базе пользователей, а она различается на хосте и в образе контейнера. Поэтому каталоги, подключённые через bind mount, часто показывают странных владельцев или становятся недоступными для записи: процесс контейнера работает как UID 33 (www-data в образах Debian) или 1000 (node в официальных образах Node), а файлы на хосте принадлежат вашему deploy-пользователю. Решения, от самого простого: запускать контейнер с UID и GID хоста (user: "1000:1000" в Compose), сделать chown тома на UID контейнера или использовать именованные тома, которые инициализирует Docker. Rootless Docker и Podman добавляют user namespaces, так что root контейнера отображается на высокий непривилегированный UID хоста; это повышает безопасность, но сдвигает числа, которые вы видите на диске. DynamicUser в systemd в том же духе выделяет временный UID на каждый сервис.

1docker compose exec app id                  # UID inside the container
2stat -c '%u:%g %n' ./storage                # numeric owner on the host
3# docker-compose.yml
4#   services:
5#     app:
6#       user: "1000:1000"                   # match the host deploy user
7cat /etc/subuid                             # ranges for rootless containers