Права доступа в Linux: chmod, chown и umask простыми словами

Три набора прав: владелец, группа, остальные

Каждый файл и каталог в Linux имеет ровно одного владельца (user) и ровно одну связанную группу (group), а права доступа к нему описываются тремя независимыми наборами флагов: отдельно для владельца, отдельно для его группы и отдельно для всех остальных пользователей системы. Именно эта модель, устоявшаяся ещё в ранних версиях Unix, остаётся основой контроля доступа в любом современном Linux-дистрибутиве, включая тот, что установлен на типичном VPS.

Каждый из трёх наборов состоит из трёх независимых флагов: чтение (r, read), запись (w, write) и выполнение (x, execute). Комбинация из девяти битов — по три на владельца, группу и остальных — и определяет, кто именно и что именно может сделать с конкретным файлом или каталогом.

ls -l /var/www/example.ru/index.php\n# -rw-r--r-- 1 www-data www-data 2048 сен 20 10:00 index.php

Строка -rw-r--r-- читается так: первый символ определяет тип объекта (- для обычного файла, d для каталога, l для символьной ссылки), затем идут три триады по три символа — rw- для владельца (чтение и запись, без выполнения), r-- для группы (только чтение) и r-- для всех остальных (тоже только чтение). Прочерк на месте буквы означает, что соответствующее право не выдано.

Для каталогов смысл трёх флагов немного отличается от смысла для файлов. Чтение каталога позволяет получить список имён файлов внутри него; запись позволяет создавать, удалять и переименовывать записи внутри каталога (не путать с изменением содержимого самих файлов); а выполнение — это право «войти» в каталог и обратиться к конкретному файлу внутри по известному имени, даже если право на чтение (листинг) при этом отсутствует.

Узнать, под каким пользователем и в каких группах вы сейчас работаете, можно командами whoami и id — это первый шаг при разборе почти любой проблемы с правами доступа, поскольку без понимания «кто я в данный момент с точки зрения системы» дальнейшая диагностика прав доступа лишена смысла.

Числовой и символьный синтаксис chmod

Команда chmod меняет права доступа к файлу или каталогу и поддерживает два равноценных синтаксиса — числовой (октальный) и символьный. Числовой синтаксис опирается на то, что каждому из трёх флагов присвоен вес: чтение равно 4, запись равно 2, выполнение равно 1, а сумма весов внутри одной триады даёт единственное число от 0 до 7.

chmod 755 deploy.sh\nchmod 644 config.php

В примере выше 755 расшифровывается как rwxr-xr-x: владелец получает полный доступ (4+2+1=7), группа и остальные — чтение и выполнение (4+1=5) без права на запись. 644 расшифровывается как rw-r--r--: владелец может читать и писать, группа и остальные — только читать. Эти два набора чисел покрывают подавляющее большинство практических случаев для файлов сайта.

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

chmod u+x deploy.sh\nchmod go-w secret.env\nchmod o=r public.txt

Ключевое практическое отличие: числовой синтаксис задаёт весь набор прав явно и полностью, поэтому безопаснее использовать именно его, когда нужно привести файл к точно известному, предсказуемому состоянию — например, при массовой настройке прав после разворачивания сайта. Символьный синтаксис лучше подходит для точечных, инкрементальных правок уже существующей конфигурации прав.

Флаг -R включает рекурсивное применение chmod ко всем вложенным файлам и каталогам, но использовать его в лоб для целого сайта стоит с осторожностью: chmod -R 755 сделает исполняемыми абсолютно все файлы, включая обычные текстовые и файлы конфигурации, для которых бит выполнения не нужен и потенциально нежелателен. Правильнее развести права файлов и каталогов через find с разными масками.

find /var/www/example.ru -type f -exec chmod 644 {} \;\nfind /var/www/example.ru -type d -exec chmod 755 {} \;

chown и chgrp: смена владельца и группы

Права доступа сами по себе бессмысленны без понимания, кому именно они выданы, — за это отвечают владелец файла и его группа, которые меняются командами chown и chgrp соответственно. Синтаксис chown принимает владельца и группу через двоеточие одной командой, что удобнее двух отдельных вызовов.

chown www-data:www-data /var/www/example.ru/wp-content/uploads\nchown -R www-data:www-data /var/www/example.ru

Смена владельца файла (chown) — операция, доступная только root, независимо от того, что текущий владелец, казалось бы, «свой» файл на своём же сервере. Это осознанное ограничение: если бы обычные пользователи могли произвольно передавать файлы друг другу, это позволяло бы обходить дисковые квоты и размывать ответственность за содержимое конкретных файлов в многопользовательской системе.

Смена группы (chgrp, либо та же chown с указанием только группы через двоеточие впереди) доступна не только root — обычный пользователь может переключить группу своего файла на любую из групп, в которых он сам состоит, но не может назначить произвольную группу, к которой сам отношения не имеет.

Один из самых частых практических сценариев, где путаница с владельцем приводит к проблемам, — загрузка файлов сайта через SFTP под одним системным пользователем (например, deploy) при том, что реально сайт отдаёт nginx и обрабатывает php-fpm от имени другого пользователя (например, www-data). Файлы физически на месте, права выглядят разумно, но веб-сервер не может их прочитать или в них записать, потому что не совпадает ни владелец, ни группа.

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

umask: права по умолчанию для новых файлов

При создании нового файла или каталога операционная система не выбирает права доступа произвольно — она берёт условные базовые права (666 для файлов, 777 для каталогов) и вычитает из них маску, заданную переменной umask для текущего процесса или сессии. Результат такого вычитания и становится правами, с которыми файл появляется на диске.

umask\n# 0022

Типичное значение umask 022 при базовых правах 666 для файлов даёт в результате 644 (666 минус 022 по битам записи для группы и остальных), а для каталогов при базовых 777 даёт привычные 755. Именно поэтому большинство новых файлов на сервере по умолчанию получают ровно те права, которые считаются разумной нормой — это не совпадение, а прямое следствие настроенного umask.

umask можно изменить для конкретной сессии командой umask значение, но такое изменение действует только до конца сессии. Для постоянного изменения значение прописывают в файле профиля оболочки (~/.bashrc, ~/.profile или системный /etc/profile), а для отдельного systemd-сервиса — директивой UMask= прямо в unit-файле, чтобы новые файлы конкретного сервиса создавались с нужными правами независимо от глобальной настройки системы.

Важная деталь, которую легко упустить: изменение umask влияет только на файлы, создаваемые после этого изменения, и никак не меняет права уже существующих файлов на диске. Если на сервере годами были загружены сотни файлов с неудачным значением umask, простое исправление umask на будущее не наведёт порядок в уже накопленном; для этого всё равно потребуется явный chmod по всему дереву каталогов.

Sticky bit, setuid и setgid: специальные биты прав

Помимо обычных прав чтения, записи и выполнения, у файлов и каталогов в Linux есть три специальных бита, решающих более узкие задачи: setuid, setgid и sticky bit. Они кодируются четвёртой, старшей цифрой в числовом представлении chmod — например, 4755 вместо 755 включает setuid вдобавок к обычным правам.

chmod 1777 /var/www/shared-uploads\nchmod +t /var/www/shared-uploads

setuid, применённый к исполняемому файлу, заставляет программу выполняться с правами владельца файла, а не с правами пользователя, который её запустил, — классический пример — бинарник passwd, которому нужны права root для изменения системного файла с паролями, хотя запускает его обычный пользователь. setgid на исполняемом файле работает аналогично, но подставляет группу владельца вместо группы запускающего пользователя.

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

chmod g+s /var/www/shared-uploads

sticky bit решает третью, отдельную задачу и виден на практике прежде всего на каталоге /tmp — он доступен на запись практически всем пользователям системы, и без sticky bit любой пользователь мог бы удалить или переименовать чужой файл в этом каталоге, имея формальное право записи в сам каталог. sticky bit разрешает удаление или переименование файла только его собственнику, владельцу каталога или root, независимо от общих прав записи в каталог.

Стоит отдельно предостеречь от создания собственных setuid-программ без крайней необходимости: ядро Linux по умолчанию игнорирует setuid-бит на интерпретируемых скриптах именно из соображений безопасности, а setuid-бинарники остаются одной из частых точек эскалации привилегий при обнаружении в них уязвимостей — использовать этот механизм оправдано для проверенного системного ПО, а не для собственных скриптов.

Правильные права для файлов сайта: почему 644 и 755

Для типичного сайта на PHP, обслуживаемого связкой nginx и PHP-FPM, устоявшаяся практика — права 644 для обычных файлов и 755 для каталогов, при этом владельцем или хотя бы группой должен быть пользователь, от имени которого реально работает веб-сервер и PHP-FPM (часто это www-data, иногда nginx или отдельный пользователь конкретного сайта в зависимости от конфигурации хостинга).

Логика такой схемы проста: веб-серверу в норме нужно только читать файлы сайта, чтобы отдавать их посетителям или передавать интерпретатору PHP, а не изменять их самостоятельно — изменения в код вносит разработчик через деплой или редактирование, а не сам процесс, обслуживающий запросы посетителей. Право на запись для группы и остальных в такой модели просто не нужно и потому не выдаётся.

Каталогам, в отличие от файлов, бит выполнения нужен почти всегда — без него веб-сервер не сможет «войти» в каталог, чтобы обратиться к файлу внутри по имени, даже если права самого файла в порядке. Именно поэтому стандартная пара 644/755, а не одинаковые права для файлов и каталогов, — это не произвольный выбор, а прямое следствие разного назначения бита выполнения для файлов и для каталогов.

Исключение из этой общей схемы — каталоги для загружаемых пользователями файлов, вроде wp-content/uploads в WordPress: туда веб-серверу действительно нужно писать, поэтому владелец таких каталогов должен совпадать с пользователем PHP-FPM. При этом важно дополнительно запретить исполнение PHP-кода внутри каталога загрузок на уровне конфигурации nginx — права доступа сами по себе не мешают загруженному под видом картинки PHP-файлу быть впоследствии выполненным, если веб-сервер не настроен блокировать это явно.

location ~* /wp-content/uploads/.*\.php$ {\n    deny all;\n}

Почему chmod 777 — почти всегда неверное решение

chmod 777 открывает чтение, запись и выполнение абсолютно всем — владельцу, группе и всем остальным пользователям системы без исключения. На первый взгляд это универсальный способ раз и навсегда избавиться от ошибок Permission denied, но на практике это решение почти никогда не устраняет настоящую причину проблемы, а лишь маскирует её ценой серьёзного снижения безопасности.

Подавляющее большинство ошибок доступа на практике вызвано не тем, что владельцу файла не хватает прав, а тем, что владелец файла попросту не тот пользователь, от имени которого работает обращающийся к файлу процесс. chmod 777 «чинит» такую ситуацию побочным эффектом — доступ действительно появляется у всех, включая нужный процесс, — но правильным решением остаётся chown на корректного владельца, а не открытие файла миру.

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

Базовый принцип управления доступом в информационной безопасности

Практическая опасность файлов и каталогов с правами 777 в том, что записать в них или заменить их содержимым может уже не только легитимный владелец, но и любой другой пользователь системы. На выделенном VPS с одним проектом риск чуть ниже, но остаётся: любой скомпрометированный процесс на этом же сервере получает возможность беспрепятственно менять файлы, которым выставлен режим 777.

Автоматические сканеры безопасности и панели хостинга обычно отдельно помечают файлы с правами 777 как потенциальную уязвимость — если такое предупреждение появилось, правильная реакция не «игнорировать, раз сайт работает», а разобраться, какой процесс нуждается в записи, и выдать доступ именно ему через корректного владельца, вернув остальным разумные 644 или 755.

Диагностика ошибки Permission denied

Когда сайт или скрипт внезапно выдаёт Permission denied, разбор стоит начинать не с попытки наугад менять права, а с последовательной проверки нескольких конкретных вещей. Первый шаг — посмотреть фактические права и владельца проблемного файла командой ls -l, а для самого каталога — обязательно с флагом -d, иначе ls покажет содержимое каталога, а не его собственные атрибуты.

ls -l /var/www/example.ru/wp-content/uploads/photo.jpg\nls -ld /var/www/example.ru/wp-content/uploads

Второй шаг — понять, от имени какого пользователя реально выполняется процесс, столкнувшийся с отказом в доступе. Для веб-приложения это обычно пользователь PHP-FPM (директивы user и group в конфигурации пула), а не тот пользователь, под которым администратор заходит по SSH — это разные, часто несовпадающие учётные записи, и путаница между ними — источник значительной доли ложных выводов при диагностике.

Третья и часто упускаемая из виду причина — недостаточные права не на самом файле, а на одном из родительских каталогов по пути к нему. Файл может иметь идеальные права 644 и правильного владельца, но если у веб-сервера нет бита выполнения хотя бы на одном каталоге выше по дереву, обратиться к файлу не получится. Команда namei -l показывает права на каждом уровне пути сразу, что ускоряет поиск проблемного звена по сравнению с проверкой каждого каталога вручную.

namei -l /var/www/example.ru/wp-content/uploads/photo.jpg

Если стандартные unix-права выглядят корректными, а ошибка всё равно возникает, стоит проверить два менее очевидных источника. Во-первых, расширенные списки доступа (ACL), которые накладывают дополнительные ограничения поверх обычных прав и не видны в выводе ls -l — их показывает команда getfacl. Во-вторых, на дистрибутивах с включённым SELinux (типично для CentOS и AlmaLinux) файл может иметь идеальные unix-права, но неверный контекст безопасности, блокирующий доступ независимо от привычной модели прав, — это проверяется командой ls -Z и устраняется через restorecon.

getfacl /var/www/example.ru/wp-content/uploads\nls -Z /var/www/example.ru/wp-content/uploads

Чек-лист настройки прав для нового сайта

Шаг 1. Определите, от имени какого пользователя и группы реально работает веб-сервер и PHP-FPM на конкретном сервере — обычно это видно в конфигурации пула PHP-FPM или в конфигурации nginx/apache.

Шаг 2. Приведите владельца и группу всех файлов сайта к этому пользователю командой chown -R, а не оставляйте файлы во владении пользователя, использованного для загрузки по SFTP или Git.

Шаг 3. Раздельно выставьте права 644 для всех файлов и 755 для всех каталогов через find с разными масками, а не единым chmod -R для всего дерева.

Шаг 4. Для каталогов, куда веб-серверу действительно нужно писать (загрузка файлов, кэш, временные файлы), убедитесь, что владелец совпадает с пользователем PHP-FPM, и дополнительно запретите выполнение PHP внутри таких каталогов на уровне конфигурации веб-сервера.

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

Шаг 6. Убедитесь, что нигде в проекте не осталось chmod 777, оставшегося от попытки быстро «починить» доступ в прошлом, и что каждое действительно нужное расширение прав выдано конкретному владельцу или группе, а не всем подряд.

Итог: права доступа решают конкретную задачу, а не создают неудобства

Модель прав доступа Linux — не бюрократическое ограничение, придуманное, чтобы мешать администратору, а рабочий инструмент, который в правильно настроенном виде делает поведение сервера предсказуемым: понятно, кто именно может прочитать, изменить или выполнить каждый конкретный файл, и это можно проверить одной командой ls -l, а не гадать по факту произошедшего инцидента.

Подавляющее большинство практических проблем с правами доступа сводится к одной из трёх причин: неверный владелец файла (лечится chown), недостаточные права на одном из родительских каталогов (лечится проверкой цепочки через namei), либо неудачно настроенный umask, из-за которого новые файлы создаются с неподходящими правами. Понимание этих трёх сценариев закрывает почти весь набор реальных ситуаций без необходимости прибегать к chmod 777 как к универсальному, но опасному обходному пути.

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