Русский

Инструменты разработчика · Калькулятор Chmod

Исправление nginx 403 Запрещено: важные права доступа к файлам и каталогам

· Почему это важно

chmod Юникс контроль доступа

Диагностика корневого веб-сайта отображается в виде отдельной диаграммы битов разрешений Unix
Оригинальная векторная иллюстрация ToolAcre

403 из nginx часто является проблемой файловой системы, а не проблемой конфигурации. В этом посте показано, как проверить, от имени какого пользователя работает nginx и какие биты ему нужны в каждом каталоге на пути.

403 на статическом сайте, который работал локально — файлы взяты из /home/deploy, а nginx говорит, что запрещено для каждого URL

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

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

403 может включать биты режима, но этот маршрут не может определить его причину.

Калькулятор не может определить личность работника nginx. Он моделирует владельца, группу и другие классы, но не моделирует имена пользователей, процессы или членство. Таким образом, такой режим, как rwxr-xr-x, ничего не говорит о том, владеет ли работник объектом, принадлежит ли он к своей группе или подпадает под другую. Внешний осмотр должен установить эту классификацию.

Обнаружение личности должно предшествовать утверждениям о соответствующих битах. Как только свидетельства установят применимый класс, в матрице отображается чтение как 4, запись как 2 и выполнение как 1. До этого редактирование группы или чего-то еще остается догадкой. Маршрут не считывает состояние процесса; он преобразует предоставленные режимы, а не выводит архитектуру сервера.

Калькулятор не обнаруживает личность работника nginx

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

Браузер не переходит от корня к корню веб-сайта. Он не может обнаружить блокирующий компонент, подтвердить его существование или проверить списки ACL. Укажите каждый наблюдаемый режим каталога отдельно, а затем проверьте конечный объект как обычный файл, где чтение касается содержимого, а не списков. Это интерпретирует собранные данные вместо замены проверки файловой системы.

Файлам нужен r и ничего больше — почему 644 достаточно для статических файлов и почему 755 для файлов не является исправлением

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

Сохраняйте четкое описание файлов и каталогов. Выполнение каталога означает доступность входа и имени, тогда как выполнение обычного файла означает запуск программы. Таким образом, один и тот же флажок имеет конкретную целевую формулировку. Сравнение 644 с 755 проясняет биты, но не позволяет диагностировать 403 или предписывать универсальный режим без конфигурации, идентификации, ACL и контекста политики.

Рабочий пример: трассировка /home/deploy/site/index.html — namei -l по пути и строки ls -l, которая показывает блокировщик

Поддерживаемый пример начинается после того, как доказательства пути собраны в другом месте. Предположим, что компоненты каталога — 755, а конечный файл — 644. Калькулятор отображает каталоги как rwxr-xr-x, объясняя группу и другие действия как вход и доступность. Он отображает файл как rw-r--r--, объясняя групповое и другое чтение как доступ к содержимому.

Если компонент — 750, его другая тройка — ---, а группа остаётся r-x. Эта разница может иметь значение, но не доказывает, что nginx использует другую версию. Маршрут не может выполнять namei или ls, поэтому пути и режимы должны предоставляться внешними данными. Затем он синхронизирует каждое представление, чтобы уменьшить ошибки транскрипции во время просмотра.

Рабочий пример: проверьте предоставленные режимы для каждого компонента пути.

Решения о собственности остаются вне режима преобразования. Панель не считывает владельца или группу и не предлагает никаких операций chown или chgrp. Он не может выбирать между развертыванием, обслуживанием или владением общей группой, а также оценивать перемещение контента. Эти решения требуют наличия данных о системе и рабочей нагрузке, отсутствующих в источниках; никакой сгенерированный режим не может заменить этот контекст.

Как только право собственности будет решено в другом месте, сравните, как режимы делят доступ. Режим 750 предоставляет полные права владельцу, групповому чтению и выполнению и ничего другим; 755 добавляет другие операции чтения и выполнения. Это остается при условии знания класса рабочего. Предварительный просмотр инертной команды не меняет владельца и не подтверждает доступ к серверу.

Выбор владельца остается внешним по отношению к преобразованию режима.

Конфигурация, выбор индекса, обязательное управление доступом и поведение восходящего потока здесь не диагностируются. Ни один источник не загружает конфигурацию nginx, не проверяет URI или индекс, не читает журналы, не связывается с вышестоящим сервером или не наблюдает за SELinux или AppArmor. Поэтому правильное преобразование предоставленного режима не может установить, почему nginx вернул 403; Доказательства сервера должны ответить на этот вопрос.

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

Конфигурация, индекс, MAC и вышестоящие причины не диагностируются

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

Установите личность сервера и соберите режимы пути за пределами этого маршрута. Декодируйте каждый каталог как каталог, а конечный объект — как обычный файл, ориентируясь на внешне проверенный класс. Изучите конфигурацию, списки управления доступом и обязательную политику отдельно. Калькулятор проверяет арифметику, но не может определить причину 403 или проверить исправление.