Права WordPress

Слово «права» в разговоре о WordPress означает разные вещи. Хостинг-провайдер говорит о правах на файлы: кто может читать и изменять код сайта на диске. Разработчик плагина — о правах пользователя: может ли автор опубликовать запись или только отправить её на проверку. Эти уровни независимы, но взлом обычно начинается со стыка между ними.

Права на файлы

На сервере файлы сайта принадлежат какому-то системному пользователю, а PHP работает от имени своего. Если они совпадают, WordPress может сам ставить плагины и обновления. Если нет и записать файл не получается, при обновлении появляется форма с запросом данных FTP. Числовая запись прав вроде 644 и 755 разобрана на странице прав файлов CHMOD.

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

Права пользователей

Внутри WordPress действия разрешаются через возможности: edit_posts, publish_posts, manage_options, install_plugins. Роль — это набор таких возможностей. В своём коде проверяют именно возможность, а не название роли:

if ( ! current_user_can( 'edit_post', $post_id ) ) {
    wp_die( 'Недостаточно прав' );
}

Константы, которые связывают оба уровня

Даже администратор не должен иметь возможность править PHP-код из браузера: украденный пароль тогда сразу превращается в полный контроль над сервером. Две строки в wp-config.php закрывают эту дверь:

define( 'DISALLOW_FILE_EDIT', true ); // убрать редактор тем и плагинов
define( 'DISALLOW_FILE_MODS', true ); // запретить установку и обновление из админки

Вторая константа строже: она отключает и установку плагинов, и автообновления. Её включают там, где обновления проходят через тестовую копию и выкладку.