Перейти к содержимому
BXWiki

Права на файлы и папки - файловая система и права структуры

Разбираемся с двумя механизмами прав, которые постоянно путают: правами файловой системы и правами структуры сайта внутри платформы.

Решение

Смотрим, под кем работает сайт и кому принадлежат файлы:

Окно терминала
ps -o user= -C php-fpm | sort -u        # пользователь процессов PHP
ls -ld /home/bitrix/www/upload/ /home/bitrix/www/bitrix/cache/
find /home/bitrix/www/upload -user root | head   # файлы, залитые от чужого имени

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

Возвращаем владельца после ручного копирования:

Окно терминала
chown -R bitrix:bitrix /home/bitrix/www/
find /home/bitrix/www -type d -exec chmod 755 {} \;
find /home/bitrix/www -type f -exec chmod 644 {} \;
# режим 777 не лечит причину, а открывает файлы всем на сервере

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

Выдаём группе доступ к разделу сайта:

// файл .access.php внутри папки раздела
$PERM['/upload/private/']['5'] = 'R';    // группа 5 - только чтение
$PERM['/upload/private/']['6'] = 'W';    // группа 6 - запись
// права наследуются вложенными папками, пока не переопределены своим файлом

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

Проверяем доступ из кода:

global $APPLICATION;
$level = $APPLICATION->GetFileAccessPermission('/upload/private/');
printf("уровень доступа=%s\n", $level);   // D - запрет, R - чтение, W - запись
// проверяют от имени конкретного пользователя: у администратора уровень свой

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

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

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

Типичные проблемы

Сайт пишет об отсутствии прав на запись.

Владелец файлов не совпадает с пользователем процессов PHP на сервере. Так бывает после ручного копирования от имени администратора сервера.

После открытия всех прав ошибка ушла.

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

Права на раздел сбросились после выкладки.

Служебный файл прав раздела не попал в перенос. Он скрытый, и обычное копирование каталога его пропускает.

У менеджера нет кнопки, хотя права выданы.

Права выданы на другом уровне: на диске или на другой раздел сайта. Уровень доступа к конкретному пути проверяют вызовом из кода.

Загруженные файлы недоступны посетителям.

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

Частые вопросы

Какие права ставить на каталоги и файлы?

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

Почему после переноса сайт не пишет в загрузки?

Файлы приехали от имени другого пользователя. Владельца возвращают одной командой по всему каталогу сайта.

Права структуры хранятся в базе?

Нет, отдельным файлом в самой папке. Поэтому они переносятся вместе с файлами, если копировать скрытые файлы тоже.

Как закрыть папку от посторонних?

Правами структуры для групп и запретом на уровне веб-сервера для прямых ссылок. Один механизм без второго оставляет обходной путь.

Смежное

Первоисточник