Управление пользователями и правами доступа в Linux

Миф о «волшебной» команде chmod 777: почему это катастрофа для безопасности

Самый частый «совет» из сомнительных форумов — выдать полный доступ на папку командой chmod -R 777. Как инженер техподдержки, скажу прямо: это мгновенное решение, которое гарантированно создаст проблему через месяц, когда кто-то случайно затрёт чужие файлы или подцепит шелл через веб-сервер. Нюанс в том, что 777 не учитывает umask процесса и не даёт точечной настройки. Вместо этого используйте chmod u=rwx,g=rx,o=rx для каталогов и chmod 644 для файлов. Если лень разбираться — просто никогда не пишите 777 в продакшне.

Sticky Bit: как не дать пользователям «убивать» чужие файлы в общих папках

Вы настроили общую папку /tmp или /shared, дали групповой доступ, а через день пользователи жалуются, что их файлы пропадают. Типичная ошибка новичка: права 777 кажутся очевидными, но они позволяют удалять файлы любому, у кого есть права на запись в каталог. Профессионалы всегда ставят chmod +t (Sticky Bit) на общие каталоги. Посмотрите на /tmp в любой системе — у него права 1777. Это значит, что файл может удалить только его владелец или root. В техподдержке это спасёт вас от сотен обращений «куда делся мой отчёт».

ACL: когда стандартных прав недостаточно, но никто не знает, как это работает

Стандартная тройка u/g/o часто ломается, когда нужно дать доступ к файлу трём конкретным людям из разных групп. Вместо того чтобы плодить группы или копировать файлы, используйте ACL (Access Control Lists). Команда setfacl -m u:ivan:rwx file.txt даст доступ только Ивану, не трогая остальных. Частый баг: после ручного chmod ACL сбрасывается (chmod перезаписывает маску). Поэтому если вы правили ACL, никогда не используйте chmod с абсолютными числами (777, 755 и т.д.) — лучше chmod u+rwx. В диагностике tech support всегда проверяйте getfacl — он покажет реальную картину, которую ls -l часто искажает.

SUID и SGID: два бита, которые ломают безопасность, если не знать нюансов

Вы дали бит SUID на скрипт, чтобы он выполнялся от root, и получили дыру в безопасности. Эксперты знают: SUID на скриптах оболочки (bash, python) игнорируется большинством современных ядер Linux из-за опасности атак через переменные окружения (LD_PRELOAD). Работает SUID только на бинарниках. Но даже с бинарниками будьте аккуратны: если программа имеет баг (например, старый crontab), злоумышленник получит root. В техподдержке чаще встречается SGID на папках: chmod g+s directory. Это гарантирует, что новые файлы наследуют группу папки, а не группу создателя. Если у вас в логах появились файлы с группой nobody — скорее всего, забыли SGID.

Группы: не плодите лишних, используйте secondary groups

Типичная ошибка админа — создать для каждого сервиса отдельную primary group и мучиться с usermod -g. Правильный подход: основная группа (primary group) — только для пользователя (обычно одноимённая), а все доступы давать через дополнительные группы (secondary group). Пример: usermod -aG docker,builders ivan. Если вы меняете primary group у root — вы ломаете систему. Нюанс: группы применяются только при новом входе в систему. Если пользователь сидит в сессии и вы добавили его в группу — он не получит доступ до перезапуска сессии. Для техподдержки: команда id покажет все группы процесса, а groups — только файла /etc/group.

sudoers: write-only конфиг, или как не запереть себя вне системы

Самое опасное действие — редактировать /etc/sudoers текстовым редактором, не используя visudo. Ошибка синтаксиса (пропущенная запятая, лишний пробел) приведёт к тому, что sudo перестанет работать. visudo проверяет синтаксис перед сохранением. Профессиональный совет: давайте права на конкретные команды, а не ALL. Например, user1 ALL=(ALL) /bin/systemctl restart nginx вместо ALL=(ALL) ALL. Второе — это root без пароля. Если нужен полный доступ — создайте отдельную группу wheel или sudo, а не раздавайте всем подряд.

Наследование прав и umask: почему новые файлы имеют неправильные права

Инженеры техподдержки часто слышат: «Я поставил права 777 на папку, а новый файл внутри создаётся с 644!». Дело в umask — маске по умолчанию, которая вычитается из 666 для файлов и 777 для папок. Если umask = 022, файл получает 644. Чтобы новым файлам дать групповую запись, нужно изменить umask: umask 002 (даёт 664). Нюанс: umask задаётся в ~/.bashrc или в глобальном /etc/profile. Не делайте umask 000 для всех — это дыра. Для веб-серверов используйте usermod -aG www-data и umask 002 для группы, чтобы скрипты могли писать в кеш.

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

Когда пользователь пишет «не пускает», не гадайте. Смотрите journalctl -xe или /var/log/auth.log. Стандартная ошибка: Permission denied с селйнуксом. Многие забывают, что на RHEL/CentOS/Fedora по умолчанию включён SELinux. Если вы дали все права chmod, а доступ всё равно есть только через ls -Z — проблему нужно править через semanage fcontext или restorecon. Никогда не отключайте SELinux, игнорируя его, это частая причина неуловимых багов.

Добавлено: 25.04.2026