Что означает drwxr-xr-x в правах доступа Linux

Что означает drwxr-xr-x

drwxr-xr-x описывает директорию, которую владелец может изменять, а любой другой пользователь может читать и переходить в неё, не внося никаких изменений. В восьмеричном представлении этот режим равен 755. Linux выводит эти десять символов в начале каждой строки вывода ls -l, и они всегда означают одно и то же в одном и том же порядке, поэтому изучение одной строки позволяет понять их все.

Одно правило важнее остальных, так как от него зависит, будут ли результаты вашего тестирования достоверными. Пользователь root игнорирует биты прав доступа. Ядро предоставляет root привилегию CAP_DAC_OVERRIDE (обход дискреционного управления доступом), поэтому root открывает файлы, режим которых это запрещает. Любой пример на этой странице сработает для root, независимо от установленных битов. Выполняйте вход под обычным пользователем, если хотите увидеть работу правил в действии.

Десять символов по очереди

Создайте каталог и файл для проверки. Никакие действия в этом разделе не затрагивают ничего за пределами нового каталога.

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

При стандартном значении umask 022 две строки для каталога начинаются с drwxr-xr-x, а строка для файла — с -rw-r--r--.

Первый символ обозначает тип файла, а не права доступа. d — это каталог. - — обычный файл. l — символическая ссылка. c и b — узлы символьных и блочных устройств. s — сокет, а p — именованный канал (pipe). Этот символ не входит в восьмеричное значение, поэтому drwxr-xr-x превращается в 755, а не в число, начинающееся с d.

Девять последующих символов разбиты на три группы по три, и их порядок никогда не меняется.

• Символы со 2 по 4 — это триада владельца, биты которой применяются к пользователю, владеющему файлом.
• Символы с 5 по 7 — это триада группы, биты которой применяются к группе файла.
• Символы с 8 по 10 — это триада остальных, биты которой применяются ко всем остальным пользователям.

Внутри триады позиции всегда соответствуют r, затем w, затем x, а прочерк означает, что бит выключен. Буквы никогда не меняют своего положения. r-x — это чтение без записи. -w- — это запись без чтения, что технически допустимо, но встречается редко.

Таким образом, drwxr-xr-x разделяется следующим образом: d для каталога, затем rwx для владельца, затем r-x для группы, затем r-x для остальных.

Некоторые системы выводят одиннадцатый символ. Точка в конце, drwxr-xr-x., означает, что файл имеет контекст SELinux (Security Enhanced Linux), который дистрибутивы вроде Fedora и Rocky выводят по умолчанию. Знак «плюс» в конце, drwxr-xr-x+, означает, что для файла задан POSIX ACL (список контроля доступа) — дополнительный набор правил, выходящий за рамки этих девяти битов. Просмотреть эти дополнительные правила можно с помощью getfacl <path>.

Права r, w и x работают по-разному для директорий

Это первое правило, которое часто понимают неверно. Буквы прав доступа совпадают для файлов и директорий, но предоставляемые ими возможности различаются.

• r для файла позволяет прочитать его содержимое. r для директории позволяет просмотреть список имен файлов в ней, что необходимо для выполнения команды ls.
• w для файла позволяет изменять его содержимое. w для директории позволяет добавлять и удалять записи в ней. Удаление файла — это изменение директории, поэтому право на запись в директории является решающим, а права на сам файл при этом не учитываются.
• x для файла позволяет запустить его как программу. x для директории позволяет выполнять переход через неё (traverse), что означает возможность ядра разрешить имя внутри этой директории при поиске пути.

Возможность перехода часто вызывает удивление. x для директории не означает выполнение чего-либо. Чтобы открыть /srv/site/index.html, необходимо иметь x для /, затем x для /srv, затем x для /srv/site и, наконец, r для самого файла. Если в этой цепочке хотя бы у одной директории отсутствует право x для вас, поиск прерывается, и вызывающий процесс получает ошибку Permission denied для всего пути, даже если конечный файл доступен для чтения всем. Команда namei -l /srv/site/index.html выводит каждый шаг цепочки с указанием прав и владельца, что позволяет увидеть, на каком этапе происходит блокировка.

Директория с правом r, но без права x — это специфическое промежуточное состояние. Обычный пользователь может просмотреть список имен, так как это право дает r, но не может получить метаданные (stat) любого элемента. В результате ls -l заполняет столбцы размера и прав знаками вопроса и выводит ls: cannot access ...: Permission denied для каждого элемента.

Установка прав доступа 755

Каждая триада представляет собой трехбитовое число. r соответствует 4, w — 2, x — 1. Сложите значения активных битов.

• rwx равно 4 + 2 + 1 = 7
• rw- равно 4 + 2 = 6
• r-x равно 4 + 1 = 5
• r-- равно 4
• --- равно 0

Таким образом, drwxr-xr-x дает 7 для владельца, 5 для группы и 5 для остальных: 755. -rw-r--r-- дает 6, 4, 4: 644. drwxrwxr-x дает 7, 7, 5: 775, что соответствует 755 с добавленным правом на запись для группы. Вам не нужно считать символы вручную, так как stat выводит обе формы одновременно.

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A — это буквенная форма, %a — восьмеричная, а %U и %G указывают владельца-пользователя и владельца-группу.

Строки прав доступа, которые часто ищут

Это режимы доступа, с которыми вы столкнетесь на реальном сервере, с указанием восьмеричного значения и примерами их использования.

• -rw-r--r-- — это 644. Обычные файлы, которые сервис только читает, например, файл конфигурации или HTML-страница.
• -rw------- — это 600. Секретные данные: закрытый ключ SSH или файл .env приложения.
• -rw-rw-r-- — это 664. Файл в директории, доступной группе, где участникам команды требуется право на запись.
• -rwxr-xr-x — это 755. Скрипты и бинарные файлы, такие как /usr/local/bin/backup.sh и большинство файлов в /usr/bin.
• -rwx------ — это 700. Приватный скрипт, который может запускать только его владелец.
• drwxr-xr-x — это 755. Почти любая системная директория и корневая директория веб-сайта.
• drwx------ — это 700. ~/.ssh и домашние директории на защищенном сервере.
• drwxrwxr-x — это 775. Директория, в которую может писать группа владельца.
• drwxrwsr-x — это 2775. То же самое, плюс бит setgid, чтобы новые файлы внутри наследовали группу директории.
• drwxrwxrwt — это 1777. /tmp. Завершающая t — это sticky bit, благодаря которому пользователь может удалять только свои собственные файлы.
• -rwsr-xr-x — это 4755. Бинарный файл с установленным setuid, который выполняется от имени владельца, например, /usr/bin/passwd и /usr/bin/sudo.
• -rw-rw-rw- — это 666, а drwxrwxrwx — это 777. Доступ на запись для всех, что на сервере почти всегда является ошибкой.
• lrwxrwxrwx — это то, что отображается для любой символической ссылки. Linux игнорирует биты режима на самой ссылке и проверяет целевой объект, поэтому эта строка не несет никакого смысла.

Какая триада к вам относится

Это второе правило, в котором новички часто ошибаются. Ядро выбирает ровно одну триаду и на этом останавливается.

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

Из этого следуют два вывода. Триада владельца применяется, даже если она самая строгая. Файл с режимом 0466, который отображается как -r--rw-rw-, дает владельцу только право на чтение, в то время как все остальные могут записывать данные, потому что проверка владельца сработала первой, а последующие проверки не выполнялись. Это допустимо, и такая ситуация сбивает с толку всех при первой встрече.

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

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id выводит вашего пользователя и все группы, в которых вы состоите. stat выводит владельца и группу файла. Сравните их, и вы узнаете, какую триаду ядро будет использовать для вас.

Именно поэтому общая директория обычно получает группу и бит setgid. sudo chmod 2775 /srv/shared отображается как drwxrwsr-x, и файлы, созданные внутри, наследуют группу директории, а не личную группу создателя, в то время как новые поддиректории также получают бит setgid. Setgid устанавливает группу, а не режим доступа. При стандартном umask 022 новый файл внутри все равно получает права 644, поэтому коллеги могут читать его, но не могут записывать. Для записи группой требуется umask 002 для всех, кто там работает, или ACL по умолчанию для директории, который заменяет umask для создаваемых внутри файлов. Предоставление каждому сервису собственной учетной записи — это вторая часть данной темы, она описана в один пользователь Linux на сервис на VPS.

umask определяет права доступа для каждого нового файла

Новый файл не получает права доступа от вас. Он получает их от программы, которая его создала, за вычетом битов, которые удаляет ваш umask. Umask — это маска битов для удаления, поэтому более высокое значение umask делает файлы более закрытыми.

Большинство дистрибутивов поставляются со значением 022. Программа, создающая обычный файл, обычно запрашивает 0666. Программа, создающая каталог, обычно запрашивает 0777. Umask удаляет 022 из обоих запросов, поэтому вы получаете 644 для файлов и 755 для каталогов. Это именно та пара прав, которую вы видите повсюду на свежеустановленном VPS.

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S выводит то же значение в виде букв, что легче читать, чем 0022. Установите umask 027 в ~/.profile для более строгих настроек по умолчанию: 640 для файлов и 750 для каталогов, чтобы ваша группа могла читать вашу работу, а остальные — нет. Эти результаты предполагают стандартные запросы 0666 и 0777.

Важны два ограничения. Umask может только удалять биты, но никогда не добавлять их. Файл, запрашиваемый как 0666 (именно это запрашивает touch), никогда не станет исполняемым, что бы вы ни установили. Программа, которая запрашивает доступ только для владельца, сохраняет его: mktemp создает файлы с правами 600 и каталоги с 700 как при umask 022, так и при 027. А systemd-сервис никогда не читает ваш профиль оболочки, поэтому устанавливайте значение непосредственно в файле юнита.

[Service]
UMask=0027

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

Почему для веб-файлов используются права 644, а для директорий — 755

Веб-сервер работает от имени собственного пользователя: www-data в Debian и Ubuntu, nginx в Rocky и Alma. Этот процесс должен иметь права на чтение файлов, которые он отдает, и на переход (traverse) по директориям, в которых они находятся. У него нет причин записывать данные в эти файлы, а для статического сайта такая возможность должна быть исключена.

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

Правило перехода по директориям критично именно здесь. Если сайт расположен в /home/deploy/site, права на /home/deploy установлены как 750, а веб-пользователь не входит в группу этой директории, он не сможет войти в домашнюю директорию вовсе. Запрос завершится ошибкой HTTP 403, а в /var/log/nginx/error.log появится запись вида:

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

Число 13 — это EACCES, отказ в доступе на уровне ядра. С сетью всё в порядке: порт прослушивается, запрос дошел до сервера. Именно это часто сбивает с толку тех, кто изучает как работают прослушиваемые порты в Linux. Выполните namei -l /home/deploy/site/index.html и проверьте всю цепочку путей, чтобы найти первую директорию, у которой отсутствуют права x для остальных пользователей.

Исключением являются директории, в которые приложение должно записывать данные, например, путь для загрузки файлов. Предоставьте доступ через смену владельца, а не через расширение прав: используйте sudo chown -R www-data:www-data /srv/site/uploads, оставив права 755. Ограничьте право на запись только той директорией, которой это действительно необходимо.

chmod без изменения прав для всего дерева каталогов

chmod поддерживает обе формы записи. Восьмеричная форма устанавливает все девять битов прав одновременно: chmod 644 notes.txt. Символьная форма изменяет только указанные вами права, оставляя остальные без изменений: chmod u+x deploy.sh добавляет право на выполнение для владельца, а chmod go-w notes.txt удаляет право на запись для группы и остальных пользователей.

Рекурсивное применение команд часто приводит к повреждению прав доступа в дереве каталогов. chmod -R 755 . делает исполняемыми все изображения и файлы конфигурации, так как chmod не может отличить скрипт от файла JPEG. Используйте вместо этого флаг X.

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

Флаг X применяет право на выполнение только к каталогам и к тем файлам, у которых уже был установлен хотя бы один бит выполнения. В результате права на каталоги становятся 755, на обычные файлы — 644, а скрипты, которые уже были исполняемыми, сохраняют свои права. Если у вас есть файл с правами, которым вы доверяете, chmod --reference=good.sh other.sh позволяет скопировать их на другой файл.

Сообщения об ошибках при неверных битах прав доступа

bash: ./deploy.sh: Permission denied означает, что у скрипта отсутствует бит x в соответствующей вам триаде прав, либо у одного из каталогов в пути к нему нет бита x. Команда chmod u+x deploy.sh исправляет первый случай.

bash: ./deploy.sh: cannot execute: required file not found — это другая ошибка с запутывающим названием. Бит x установлен корректно, но отсутствует интерпретатор, указанный в первой строке файла. Частая причина — использование переносов строк в формате Windows, из-за чего ядро ищет интерпретатор с именем /bin/bash\r. Исправьте это с помощью sed -i 's/\r$//' deploy.sh.

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. выдается SSH-клиентом, который отказывается использовать закрытый ключ, доступный для чтения другим учетным записям. Для ключа требуются права 600, а для ~/.ssh — 700. Полное руководство по работе с ключами приведено в разделе управление SSH-ключами и правами доступа к файлам.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh появляется в журнале сервера, если домашний каталог или его .ssh доступны для записи группе. Настройка StrictModes в sshd отклоняет ключ, что на стороне клиента выглядит как неожиданный запрос пароля без пояснений.

sudo: /etc/sudoers is world writable, за которым следует sudo: no valid sudoers sources found, quitting, означает, что sudo проверил права доступа к собственному конфигурационному файлу и отказался запускаться. Этот файл должен иметь права 0440 и ни в коем случае не должен быть доступен для записи всем пользователям. Это классическое последствие применения рекурсивной команды chmod ко всему каталогу; такая ошибка может возникнуть одновременно с сообщением sshd, упомянутым выше, что оставляет консоль провайдера единственным способом восстановления доступа.

Почему 777 — это не решение

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

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

Права 777 почти всегда являются неверным ответом на вопрос о правах владения. Симптом проблемы звучит как «приложение не может писать в эту директорию». Причина заключается в том, что директория принадлежит не тому пользователю. sudo chown -R appuser:appuser /srv/app/storage с режимом 755 решает эту задачу: приложение может писать в директорию, а все остальные учетные записи могут просматривать её содержимое и входить в неё, но не могут вносить изменения. Создание соответствующих учетных записей до развертывания чего-либо относится к разделу первые десять минут на новом VPS.

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

Изучите режим перед его изменением

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

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 выводит список всех объектов по указанному пути, у которых установлен бит записи для всех пользователей (world write bit). Это самый быстрый способ провести аудит системы после того, как кто-то исправлял проблемы с помощью chmod 777.

Чтобы проверить, может ли конкретная сервисная учетная запись войти в каталог, выполните проверку от имени этой учетной записи. sudo -u www-data test -x /srv/site && echo yes || echo no выводит yes, если у пользователя есть право на проход (traverse) по каталогу, и no, если его нет. Проверка от имени root ничего не доказывает, так как root игнорирует эту проверку, и ответом всегда будет yes.

FAQ

Что означает drwxr-xr-x в Linux?

Это каталог, на что указывает начальный символ d, с правами доступа 755. Триада владельца — rwx, поэтому владелец имеет все права на него. Триада группы — r-x, а триада остальных пользователей — r-x, поэтому все остальные могут просматривать список файлов внутри и переходить в каталог, но никто, кроме владельца, не может добавлять или удалять содержимое. Проверить права для любого пути можно с помощью stat -c '%A %a %U %G %n' <path>, которая выводит буквенную и восьмеричную формы рядом.

Почему для веб-файлов используются права 644, а для веб-каталогов 755?

Веб-сервер работает от имени отдельной учетной записи, www-data в Ubuntu. Ему требуется право на чтение файлов, которые он отдает, и право на переход (traverse) через все родительские каталоги; при этом у него нет причин записывать данные в эти файлы или каталоги. Права 644 дают владельцу право на запись, а всем остальным — на чтение. Права 755 дают владельцу право на запись, а всем остальным — на переход. Если приложению действительно необходимо записывать данные в каталог, следует передать этот каталог приложению с помощью chown, вместо того чтобы расширять права доступа для всех.

Означает ли бит x, что я могу выполнить каталог?

Нет. Для каталога x означает переход — право разрешить имя внутри него, пока ядро проходит по пути. cd требует этого, как и любая операция открытия файла внутри каталога. Каждый каталог на пути требует x, поэтому файл с правами 644 останется недоступным, если у одного из родительских каталогов отсутствует x для вас. namei -l /path/to/file выводит права доступа для каждого каталога в цепочке, что позволяет увидеть, где именно прерывается поиск.

Является ли chmod 777 когда-либо правильным решением?

Почти никогда на сервере. Это дает право на запись каждой учетной записи в системе, включая те, от имени которых работают сервисы, поэтому один скомпрометированный сервис может перезаписать файл. Если приложению не удается записать данные в каталог, реальная проблема обычно заключается во владельце: sudo chown -R appuser:appuser /srv/app/storage с правами 755 дает приложению доступ на запись, в то время как другие учетные записи могут читать каталог, но не могут вносить в него изменения. Известное исключение — /tmp с правами 1777; это работает только благодаря sticky bit, который запрещает пользователям удалять чужие файлы.

Почему ls выводит точку или плюс после прав доступа?

Этот одиннадцатый символ описывает правила, выходящие за рамки девяти битов прав доступа. Точка, как в drwxr-xr-x., означает, что применен контекст безопасности SELinux, что является нормой для Fedora и Rocky. Плюс, как в drwxr-xr-x+, означает, что установлен POSIX ACL (список контроля доступа), поэтому некоторые пользователи или группы имеют права, которые не отображаются в трех стандартных триадах. Запустите getfacl <path>, чтобы просмотреть эти дополнительные записи.