Права доступа в Linux: управление пользователями, группами и ACL

Права доступа к файлам Linux настраивают тремя основными инструментами: chmod меняет режим доступа, chown назначает владельца и группу, а setfacl добавляет точечные правила для отдельных пользователей и групп. Для новых файлов и каталогов используют umask. Учетные записи и членство в группах управляются командами useradd, groupadd и usermod.

Рабочий алгоритм выглядит так: определить требуемые операции, проверить текущие права через ls -l, stat и getfacl, назначить владельца и группу, применить минимально необходимый режим, добавить ACL при наличии исключений, затем проверить доступ от имени фактического пользователя или сервиса. Команды ниже подходят для большинства Linux-дистрибутивов, но наличие ACL-утилит и поведение отдельных файловых систем нужно проверять в конкретной среде.

Для закрытого раздела доступ получают авторизованные пользователи из разрешенной группы, например администраторы и участники группы № 7. Остальные пользователи должны получать отказ. Защищают и каталог, и прямой путь к файлам: приложение обязано проверять права перед выдачей данных.

Права доступа Linux: краткий ответ и базовый алгоритм

Какой инструмент использовать для каждой задачи

chmod не меняет владельца и не добавляет пользователя в группу. chown не задает права чтения или записи. ACL дополняет стандартную схему владелец-группа-остальные, когда трех классов доступа недостаточно.

Что проверить перед изменением прав

Сначала зафиксируйте исходное состояние и убедитесь, что путь указывает на нужный объект:

ls -ld /srv/project /srv/project/config.yml
stat /srv/project/config.yml
getfacl /srv/project/config.yml
id USER

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

Как устроены права доступа к файлам и директориям Linux

Строка ls -l начинается с типа объекта и девяти обычных разрешений:

-rwxr-x--- 1 deploy developers 4096 Aug 28 12:00 deploy.sh

Первый символ - обозначает обычный файл. Для каталога используется d, для символьной ссылки, l. Следующие три символа относятся к владельцу, следующие три к группе, последние три к остальным пользователям. В примере владелец может читать, изменять и запускать файл, участники группы могут читать и запускать его, остальные доступа не имеют.

Буквенная запись rwx

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

В символьной записи используются классы u для владельца, g для группы, o для остальных и a для всех. Операторы +, - и = добавляют, убирают или полностью задают разрешения.

Цифровая запись прав: chmod 755 и chmod 644

Восьмеричные значения строятся из суммы разрешений: r=4, w=2, x=1. Три цифры описывают владельца, группу и остальных:

Режим 755 не означает доступ ко всему пути. Он относится к одному объекту и не отменяет ACL, SELinux, AppArmor, ограничения контейнера или отсутствие права x на родительском каталоге.

Специальные права: setuid, setgid и sticky bit

Перед обычными цифрами режима могут стоять специальные биты. 4xxx включает setuid, 2xxx setgid, 1xxx sticky bit.

• setuid для исполняемого файла запускает процесс с эффективными правами владельца файла. Проверяйте такие файлы особенно внимательно.
• setgid на каталоге заставляет новые объекты наследовать его группу. Режим 2770 подходит для общего каталога рабочей группы.
• sticky bit на общем каталоге ограничивает удаление объектов их владельцем, владельцем каталога или root. Типичный пример, каталог для временных файлов.

ls -ld /srv/shared
find / -perm -4000 -type f -ls 2>/dev/null
find /srv -type d -perm -2000 -ls

Настройка прав доступа к файлам Linux с помощью chmod

Изменение прав в символьной записи

Символьная форма удобна, когда нужно изменить один флаг и сохранить остальные:

chmod u+x deploy.sh
chmod g-w shared.txt
chmod o-r secret.txt
chmod ug+rw project.db
chmod a-rwx private.key
chmod u=rw,g=r,o= config.yml

Команда chmod u+x добавляет владельцу право запуска. chmod g-w убирает запись у группы, а chmod o-r закрывает чтение для остальных. Такая запись снижает риск случайно перезаписать весь режим.

Изменение прав в цифровой записи

Типовые команды задают полный режим объекта:

chmod 600 secrets.env
chmod 640 /etc/myapp/config.yml
chmod 750 /usr/local/bin/backup.sh
chmod 2770 /srv/shared
chmod 755 /srv/www

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

Рекурсивное изменение: когда применять chmod -R

Один режим для всего дерева часто ошибочен: файлы данных обычно не должны быть исполняемыми, а каталоги требуют права прохода. Сначала выполните предварительный просмотр:

find /srv/project -type f -print
find /srv/project -type d -print

Затем обработайте типы объектов отдельно:

find /srv/project -type d -exec chmod 750 {} +
find /srv/project -type f -exec chmod 640 {} +

Используйте chmod -R только для дерева с однородным назначением и после проверки списка. После операции повторите find, ls -l и проверку доступа от имени целевого пользователя.

Управление владельцами и группами Linux: chown, chgrp и учетные записи

Как изменить владельца файла Linux с помощью chown

Команда chown меняет владельца, группу или обе сущности:

sudo chown USER /srv/project/file.txt
sudo chown USER:GROUP /srv/project/file.txt
sudo chown :GROUP /srv/project/file.txt
sudo chown -R USER:GROUP /srv/project

Смена владельца обычно требует root или sudo. Рекурсивная форма затрагивает каждый объект внутри дерева, включая скрытые файлы и чувствительные конфигурации. Перед chown -R проверьте путь, файловую систему и список объектов. Для обычного общего каталога часто достаточно сменить группу через chgrp.

Управление группами Linux для общего каталога

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

sudo groupadd developers
sudo usermod -aG developers alice
sudo usermod -aG developers bob
sudo chown -R root:developers /srv/project
sudo chmod 2770 /srv/project

Ключ -a в usermod -aG сохраняет уже имеющиеся дополнительные группы. Команда без -a заменит список групп и может лишить пользователя ранее выданного доступа. После изменения членства пользователь должен заново войти в систему. В текущей оболочке можно запустить newgrp developers, но сервисы и уже запущенные процессы нужно проверять отдельно.

Setgid на каталоге наследует группу для новых файлов и подкаталогов. Для более предсказуемых режимов можно применить ACL по умолчанию:

sudo setfacl -m d:g:developers:rwx /srv/project

Подробнее о групповой модели и RBAC в Linux, TrueNAS и Kubernetes можно прочитать в руководстве по группам безопасности через LDAP и RBAC.

Основная и дополнительные группы пользователя

Учетная запись имеет основную группу и может состоять в нескольких дополнительных группах:

id USER
groups USER
getent group developers
id

id USER показывает UID, основной GID и дополнительные группы учетной записи. Команда id без аргумента показывает группы текущей сессии. Если usermod уже выполнен, но доступ не изменился, проверьте фактические группы процесса и создайте новую сессию. Для systemd-сервиса смотрите UID и GID процесса, а не группы администратора.

ACL Linux: точечная настройка доступа пользователям и группам

ACL нужны, когда владелец, одна группа и остальные пользователи не описывают требуемую схему. Например, группе developers нужен доступ на запись, пользователю auditor только чтение, а владельца менять нельзя. Файловая система должна поддерживать ACL, а в системе должны быть доступны setfacl и getfacl.

Как проверить ACL через getfacl

getfacl /srv/project/report.txt
getfacl /srv/project

Основные записи выглядят так:

• user:: описывает права владельца;
• user:NAME: задает права конкретного пользователя;
• group:: описывает базовую группу объекта;
• group:GROUP: задает права дополнительной группе;
• mask:: ограничивает эффективные права именованных пользователей и групп;
• other:: описывает доступ остальных пользователей.

Если запись пользователя содержит rwx, а маска равна r-x, фактическая запись будет ограничена чтением и проходом. Поэтому после изменения ACL проверяйте весь вывод getfacl, включая mask.

Как выдать права через setfacl

sudo setfacl -m u:USER:rw /srv/project/report.txt
sudo setfacl -m g:GROUP:rwx /srv/project
sudo setfacl -m m::rwx /srv/project
sudo setfacl -x u:USER /srv/project/report.txt
getfacl /srv/project/report.txt

Ключ -m добавляет или изменяет запись, -x удаляет ее. Право x на каталоге нужно для прохода, поэтому ACL на файл не поможет, если пользователь не может пройти по каталогам /srv и /srv/project.

Default ACL для общих директорий

Access ACL действует на текущий объект. Default ACL задает наследуемые права для новых файлов и каталогов внутри директории:

sudo setfacl -m d:u::rwx,d:g::rwx,d:m::rwx,d:o::--- /srv/project
getfacl /srv/project

Для доступа конкретной группе можно задать правило явно:

sudo setfacl -m d:g:developers:rwx /srv/project
sudo setfacl -m d:m::rwx /srv/project

Итоговые права нового объекта зависят от default ACL, базового режима, umask и логики приложения. Создайте тестовый файл и проверьте его через getfacl, а не предполагайте результат по настройке каталога.

Когда ACL усложняют сопровождение

ACL требуют пересмотра, если в каталоге накопились десятки индивидуальных записей, неизвестно назначение правила, отсутствует описание владельца доступа или маска регулярно меняется вручную. В такой ситуации сначала попробуйте выразить модель через отдельную группу. Индивидуальные ACL оставляйте для документированных исключений и периодически проверяйте через getfacl.

Пошаговые сценарии настройки прав доступа в Linux

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

Требование: USER хранит личные данные в /srv/private/USER, другие пользователи не должны читать или изменять их.

sudo mkdir -p /srv/private/USER
sudo chown USER:USER /srv/private/USER
sudo chmod 700 /srv/private/USER
sudo -u USER touch /srv/private/USER/test.txt
sudo chmod 600 /srv/private/USER/test.txt
sudo -u OTHER ls /srv/private/USER

Критерий готовности: владелец может создавать и читать файлы, OTHER получает отказ, а администратор осознанно использует привилегии для аварийного доступа.

Общий каталог для рабочей группы

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

sudo groupadd GROUP
sudo usermod -aG GROUP USER1
sudo usermod -aG GROUP USER2
sudo mkdir -p /srv/shared
sudo chown root:GROUP /srv/shared
sudo chmod 2770 /srv/shared
sudo -u USER1 touch /srv/shared/file.txt
sudo -u USER2 sh -c 'printf update >> /srv/shared/file.txt'
getfacl /srv/shared /srv/shared/file.txt

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

Доступ сервисного пользователя к данным приложения

Сначала определите фактического пользователя процесса, например app. Конфигурации часто требуют чтения, каталог данных записи, а каталоги в пути права прохода:

sudo chown root:app /etc/myapp/config.yml
sudo chmod 640 /etc/myapp/config.yml
sudo mkdir -p /var/lib/myapp
sudo chown app:app /var/lib/myapp
sudo chmod 750 /var/lib/myapp
sudo -u app test -r /etc/myapp/config.yml
sudo -u app test -w /var/lib/myapp

Если владельца менять нельзя, выдайте сервису ACL:

sudo setfacl -m u:app:r /etc/myapp/config.yml
sudo setfacl -m u:app:rwx /srv/data
sudo -u app test -r /etc/myapp/config.yml

Разделяйте права чтения конфигурации, записи данных и запуска каталогов. Не меняйте владельца всего дерева и не используйте 777 для исправления единичного отказа.

Доступ администратора и ограниченной группы к закрытому разделу

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

sudo chown root:GROUP /srv/restricted
sudo chmod 2770 /srv/restricted
sudo setfacl -m g:GROUP:rwx /srv/restricted
sudo setfacl -m g:admins:rwx /srv/restricted
sudo setfacl -m o::--- /srv/restricted
getfacl /srv/restricted

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

Как проверить права доступа и найти причину Permission denied

Проверка режима, владельца и ACL

Начните с субъекта, который выполняет операцию:

id USER
ls -ld /srv /srv/project
ls -l /srv/project/file.txt
stat /srv/project/file.txt
getfacl /srv/project/file.txt

Сопоставьте UID и группы пользователя с владельцем, группой, именованными ACL и маской. Проверяйте эффективные права, а не только номинальную запись. Если команда запускается через сервис, найдите его UID, GID, рабочий каталог и дополнительные ограничения.

Проверка каждого каталога в пути через namei

namei -l /srv/project/file.txt

Команда показывает каждый компонент пути. Ищите отсутствие x на любом каталоге. Право чтения конечного файла не компенсирует отсутствие прохода по /srv или /srv/project.

Проверка от имени пользователя или сервиса

sudo -u USER test -r /srv/project/file.txt
sudo -u USER test -w /srv/project/file.txt
sudo -u USER cat /srv/project/file.txt
sudo -u USER sh -c 'touch /srv/project/check.txt'

Проверка под root не доказывает корректность доступа обычного пользователя. Учитывайте контейнер, namespace, systemd, фактический UID/GID, рабочий каталог и путь, который использует приложение. Проверяйте чтение, запись, создание, удаление и выполнение отдельно.

umask, наследование и контекст безопасности

umask убирает разрешения при создании новых объектов. Посмотрите значение в текущей сессии:

umask
umask -S

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

SELinux и AppArmor работают отдельным уровнем контроля. Если Unix-права, ACL и путь выглядят корректно, проверьте контекст безопасности и журналы отказов дистрибутива. Для ошибок веб-сервера полезен отдельный алгоритм диагностики ответов 403, 404 и 500, включая права PHP-FPM и SELinux.

Безопасность и контроль изменений прав в Linux

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

• chmod 777 дает лишний доступ и маскирует неправильного владельца или группу.
• Неверный владелец блокирует приложение даже при внешне подходящем режиме.
• Отсутствие x на каталоге запрещает проход к файлу.
• usermod -G без -a заменяет дополнительные группы пользователя.
• Новая группа не появляется в уже открытой сессии.
• ACL mask может уменьшить права именованной записи.
• chmod -R задает неподходящий режим файлам и каталогам разного назначения.
• Проверка только под root не отражает работу реального сервиса.

Как безопасно менять права на рабочей системе

1. Сформулируйте список разрешенных операций и субъектов.
2. Проверьте путь, тип файловой системы, владельца, группу, режим и ACL.
3. Сохраните вывод ls -l, stat и getfacl.
4. Проверьте изменение на тестовом каталоге или копии.
5. Измените минимальный набор объектов одной командой или небольшим набором команд.
6. Проверьте доступ с UID/GID целевого пользователя.
7. Зафиксируйте результат и план отката.

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

Контрольный список после настройки

• Владелец выполняет разрешенные операции.
• Участники рабочей группы читают, изменяют, создают и удаляют только нужные объекты.
• Нецелевые пользователи получают отказ.
• Новые файлы и каталоги наследуют ожидаемые группу и режим.
• Приложение продолжает работать с тем же UID/GID.
• Прямой доступ к закрытым файлам проходит через проверку авторизации и группы.
• Итоговые режимы и ACL записаны в документации.

Шпаргалка по правам доступа Linux и ответы на частые вопросы

Нужно ли выполнять все команды от root?

Нет. Собственные файлы пользователь обычно читает и изменяет без привилегий. sudo требуется для смены чужого владельца, работы с системными каталогами, добавления пользователей в группы и некоторых ACL. Используйте sudo для конкретной команды, а не постоянную root-сессию.

Что выбрать: chmod или ACL?

Используйте chmod и группы, если модель доступа укладывается в owner-group-other. ACL выбирайте для документированных исключений, когда нескольким пользователям или группам нужны разные права на один объект. Большое число индивидуальных записей повышает стоимость аудита.

Почему chmod 755 не дает доступ к файлу?

Режим 755 относится к самому объекту. Отказ может вызвать отсутствие x на родительском каталоге, неверный UID/GID, ACL mask, SELinux, AppArmor, контейнерное ограничение или неправильный путь. Выполните namei -l, getfacl и тест через sudo -u USER.

Как быстро понять, кто имеет доступ к файлу?

ls -l /path/to/file
getfacl /path/to/file
namei -l /path/to/file
id USER
sudo -u USER test -r /path/to/file

Первые четыре команды показывают потенциальные правила, последняя проверяет конкретную операцию. Для записи используйте test -w, для прохода и запуска, test -x.

Для облачного VDS или сервера, где нужно быстро развернуть Linux-среду и проверить права на реальном сервисе, можно использовать облачную инфраструктуру Timeweb Cloud. После настройки сохраните исходные параметры, выполните тесты от имени целевого пользователя и зафиксируйте итоговый режим.

Главное правило управления правами Linux: сначала определить субъект и операцию, затем настроить владельца, группу и минимальный режим, а ACL добавлять только для понятных исключений. После каждой операции проверяйте фактический доступ, права на каждый каталог пути, наследование новых объектов и контекст безопасности.