Пользователь базы данных MySQL: какие привилегии нужны?


52

Краткая инструкция по установке WordPress ( «5 минут» ) гласит:

Создайте базу данных для WordPress на своем веб-сервере, а также пользователя MySQL, который имеет все права для доступа к нему и его изменения.

При профессиональной настройке нового блога мне было интересно, как это соотносится с тем, что предлагает мне конфигурация привилегий / разрешений пользователей базы данных MySQL:

  • Данные: SELECT , INSERT, UPDATE,DELETE
  • Определение: CREATE , ALTER,DROP
  • Дополнительно: INDEX
  • Больше:
    1. LOCK TABLES
    2. REFERENCES
    3. CREATE TEMPORARY TABLES
    4. CREATE VIEW
    5. SHOW VIEW
    6. CREATE ROUTINE
    7. EXECUTE
    8. ALTER ROUTINE

Я уверен, что для первых трех групп, я назвал их Data, Definition и Extra здесь. Но как насчет других ниже записи « Больше» ? Обычно я бы сказал, что они не нужны, но я хотел бы получить второе мнение.

Ответы:


13

Другие не нужны, как вы указываете.

Кстати, что вы могли бы сделать, это условно установить пользователя / проход на основе запрашиваемой страницы. Как в непривилегированном с select / insert / update / delete для обычного использования, так и в привилегированном с добавлением определения / индекса, кроме того, при посещении страницы обновления.


1
Есть ли какие-либо ссылки на то, как условно установить пользователя / пароль на основе запрошенной страницы в среде WordPress? TA
Superjos

@superjos: Не то, чтобы я знал об этом, но суть в том, чтобы определить обычного пользователя БД select / insert / update / delete в wp-config и, когда URL-адрес совпадает с соответствующим / Страницы wp-admin (вероятно, обновить, активировать тему и активировать плагин), чтобы определить альтернативного пользователя, который может делать все остальное.
Дени де Бернарди

34

«Все привилегии» обычно означают, что вы должны передать все пользователю. Тем не мение ...

Я нашел по крайней мере одну статью, в которой утверждается, что пользователю MySQL нужны только:

  • ВЫБРАТЬ
  • ВСТАВИТЬ
  • ОБНОВИТЬ

Углубившись вглубь , я обнаружил, что для полноценной работы (автоматические обновления, установка / удаление плагина и т. Д.) WordPress требуются некоторые дополнительные разрешения:

  • УДАЛЯТЬ
  • ALTER (для обновлений)
  • СОЗДАТЬ СТОЛ
  • DROP TABLE

Также не упоминается, но имеет смысл:

  • ИНДЕКС

Но это только две надежные ссылки, которые я могу найти, которые подкреплены мнениями, опубликованными в других местах. Я по-прежнему рекомендую вам придерживаться GRANT ALL, но если вам абсолютно необходимо ограничить использование вашей БД, начните с этих 7 привилегий и полностью протестируйте, чтобы убедиться, что все работает так, как ожидалось.


Спасибо, что поделились своими мыслями. Для этого сайта я НЕ ПРЕДОСТАВЛЯЛ ВСЕ, так как это не сайт разработки, а вместо этого придерживался всего, в том числе. ИНДЕКС. Выглядит хорошо до сих пор, я думаю, что буду следить за этим в течение следующих дней, это реальный сайт вкл. много использования плагинов и тому подобное. Для ИНДЕКСА я мог бы также немного поискать ядро ​​и руководство по mysql.
Хакре

1
Просто помните, что сторонние плагины могут вызывать практически любые операторы SQL, которые они хотят ... поэтому убедитесь, что вы правильно проверили их, прежде чем устанавливать вещи в зависимости от отозванных вами привилегий.
EAMann

12

Вот что говорит Кодекс об ограничении привилегий пользователей базы данных:

Для обычных операций WordPress, таких как публикация сообщений в блоге, загрузка мультимедийных файлов, публикация комментариев, создание новых пользователей WordPress и установка плагинов WordPress, пользователю базы данных MySQL нужны только права на чтение и запись данных в базу данных MySQL; ВЫБРАТЬ, ВСТАВИТЬ, ОБНОВИТЬ и УДАЛИТЬ.

Поэтому любая другая структура базы данных и административные привилегии, такие как DROP, ALTER и GRANT, могут быть отменены. Отменяя такие привилегии, вы также улучшаете политику сдерживания.

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

http://codex.wordpress.org/Hardening_WordPress


2
Я стараюсь практиковать принцип Наименьших привилегий, когда это возможно. (Полезная) информация в кавычках больше не содержится в связанной статье Кодекса, поэтому спасибо за ее копирование здесь.
Энтони Дж. - правосудие для Моники

2

Что касается «Заметки» в сообщении Редберна, у Кодекса Wordpress также есть Предупреждение, о котором следует также прочитать об обновлениях и изменениях схемы базы данных ...

(Редактировать: я заметил, однако, что я больше не вижу «GRANT» в списке привилегий при создании или обновлении пользователя. Возможно, «CREATE» должен быть добавлен в список? Есть ли у кого-нибудь информация об этом? - с помощью Hostgator cPanel Март 2016 г. -)

ВНИМАНИЕ:
Попытка обновления без этих привилегий [ SELECT, INSERT, UPDATE, DELETE, DROP, ALTER и GRANT] может вызвать проблемы при изменении схемы базы данных. Таким образом, НЕ рекомендуется отзывать эти привилегии. Если вы чувствуете необходимость сделать это по соображениям безопасности, то сначала убедитесь, что у вас есть надежный план резервного копирования с регулярными цельными резервными копиями базы данных, которые вы протестировали, и которые могут быть легко восстановлены. Неудачное обновление базы данных обычно может быть решено путем восстановления базы данных до старой версии, предоставления соответствующих разрешений и последующего разрешения WordPress снова попробовать обновление базы данных. Восстановление базы данных вернет ее к этой старой версии, а затем экраны администрирования WordPress обнаружат старую версию и позволят вам выполнить необходимые команды SQL для нее. Большинство обновлений WordPress не меняют схему, но некоторые делают. Только основные улучшения (3,7 до 3,8, например) изменит схему. Незначительные обновления (с 3.8 до 3.8.1), как правило, не будут. Тем не менее, сохраняйте регулярную резервную копию.

Кодекс: http://codex.wordpress.org/Hardening_WordPress


0

Мое мнение такое же, как у @EAMann выше, так же как и источники, на которые он ссылался: GRANT ALL необходим для обеспечения работоспособности вашего сайта и его будущего использования. Даже на производственной площадке вы должны попробовать придерживаться руководства пользователя.

Как кто-то, кто вносит код в ядро ​​WordPress и несколько плагинов, я рекомендую вам сохранить привилегии БД по умолчанию, как предложено в руководстве пользователя (ПРЕДОСТАВЛЯЙТЕ ВСЕ ПРИВИЛЕГИИ НА wpdatabasename. * TO "wordpressusername" @ "hostname").

Исходный код WordPress (как настоящий, так и будущий) предполагает, что пользователь БД WordPress имеет все привилегии БД для данной базы данных WordPress. Если в вашей установке отсутствуют какие-либо привилегии БД, вы можете столкнуться с проблемами при обновлении WordPress и добавлении дополнительных плагинов.

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

С тех пор страница Кодекса была обновлена ​​с помощью примеров различных систем и снимков экрана. https://codex.wordpress.org/Installing_WordPress#Step_2:_Create_the_Database_and_a_User

Создание имени и пользователя Databse (через PHPMyAdmin): https://codex.wordpress.org/Install_WordPress#Using_phpMyAdmin

Создание имени и пользователя Databse (через клиент командной строки MySQL): https://codex.wordpress.org/Install_WordPress#Using_the_MySQL_Client

mysql> CREATE DATABASE wpdatabasename;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON wpdatabasename.* TO "wordpressusername"@"hostname"
    -> IDENTIFIED BY "password";
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

mysql> EXIT
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.