Користувач бази даних MySQL: Які привілеї потрібні?

Коротка інструкція з установки 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. А як щодо інших, що знаходяться нижче вступу " Більше "? Зазвичай я б сказав, що вони не потрібні, але я хотів би отримати другу думку.

Інші не потрібні, як ви вказуєте.

До речі, те, що ти можеш зробити, це умовно встановити користувача / пропуск на основі запитуваної сторінки. Як і в непривілейованому режимі вибору / вставки / оновлення / видалення для звичайного використання, а також привілейований додаток, пов’язаний із визначенням / покажчиком, додатково під час відвідування сторінки оновлення.

"Усі привілеї", як правило, означають, що ви повинні дарувати все користувачеві. Однак ...

Я знайшов хоча б одну статтю, яка стверджує, що користувачеві MySQL потрібно лише:

• ВИБІРИ
• ВСТУПИТИ
• ОНОВЛЕННЯ

Копаючи глибше , я виявив, що для повноцінної роботи (автоматизовані оновлення, встановлення / видалення плагінів тощо) WordPress потребує додаткових дозволів:

• УДАЛИТИ
• ALTER (для оновлень)
• СТВОРИТИ СТОЛІ
• ДРОПІЛЬНИЙ СТОЛ

Також не посилається, але це має сенс:

• INDEX

Але це єдині два солідних посилання, які я можу знайти, підкріплені думками, розміщеними в інших місцях. Я б все-таки рекомендую вам дотримуватися програми GRANT ALL, але якщо ви абсолютно зобов'язані обмежити використання БД, почніть з цих 7 привілеїв і протестуйте повністю, щоб переконатися, що все працює як слід.

Ось що Codex має сказати щодо обмеження привілеїв користувачів бази даних:

Для звичайних операцій з WordPress, таких як розміщення публікацій в блозі, завантаження медіа-файлів, розміщення коментарів, створення нових користувачів WordPress та встановлення плагінів WordPress, користувачеві бази даних MySQL потрібні лише читання даних та пільги на запис даних у базу даних MySQL; ВИБІР, ВСТАВКА, ОНОВЛЕННЯ та ВИДАЛЕННЯ.

Тому будь-які інші структури бази даних та права адміністрації, такі як DROP, ALTER та GRANT, можуть бути відкликані. Скасовуючи такі привілеї, ви також покращуєте політику утримання.

Примітка. Деякі плагіни, теми та основні оновлення WordPress можуть потребувати внесення структурних змін у базу даних, таких як додавання нових таблиць або зміна схеми. У такому випадку перед встановленням плагіна або оновленням програмного забезпечення тимчасово надайте користувачеві бази даних необхідні привілеї.

http://codex.wordpress.org/Hardening_WordPress

Щодо "Примітки" у публікації Redburn, у Wordpress Codex також є Попередження, яке слід також прочитати про оновлення та зміни схеми бази даних ...

(Редагувати: проте я помічаю, що я більше не бачу "ЗАРАЗ" у списку привілеїв під час створення або оновлення користувача. Можливо, "СТВОРИТИ" слід додати до списку? Хтось має інформацію про це? - використовуючи Hostgator cPanel , Березень 2016 -)

ПОПЕРЕДЖЕННЯ.
Спроба оновлення без цих привілеїв [ SELECT, INSERT, UPDATE, DELETE, DROP, ALTER and GRANT] може спричинити проблеми при зміні схеми бази даних. Таким чином, НЕ рекомендується скасовувати ці пільги. Якщо ви відчуваєте необхідність робити це з міркувань безпеки, то переконайтеся, що у вас спочатку є надійний план резервного копіювання, з регулярними цілими резервними копіями бази даних, які ви протестували, і їх можна легко відновити. Не вдалося оновити базу даних, як правило, можна вирішити, відновивши базу даних до старої версії, надавши належні дозволи та надавши WordPress спробувати оновити базу даних ще раз. Відновлення бази даних поверне її до тієї старої версії, а екрани адміністрування WordPress виявлять стару версію і дозволять виконувати на ній необхідні команди SQL. Більшість оновлень WordPress не змінюють схему, але деякі -. Лише основні оновлення (3,7 до 3,8, наприклад) змінить схему. Незначні оновлення (3.8 до 3.8.1), як правило, не будуть. Тим не менш, тримати регулярне резервне копіювання.

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

Моя думка така ж, як і @EAMann вище, а також джерела, на які він посилався: ВИГОТОВЛЯЙТЕ ВСІ необхідні для забезпечення вашого веб-сайту функціональним і майбутнього підтвердженням. Навіть на виробничому майданчику ви спробуйте дотримуватися посібника користувача.

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

Вихідний код WordPress (як теперішній, так і майбутній) передбачає, що користувач WordPress DB має всі привілеї БД для даної бази даних WordPress. Якщо у вашій програмі відсутні будь-які привілеї до БД, у вас може виникнути проблеми під час оновлення WordPress та додавання інших плагінів.

Таким чином, ви дійсно не повинні використовувати привілеї БД, відмінні від привілеїв БД за замовчуванням, рекомендованих у посібнику, якщо ви не знаєте, чим займаєтесь, маєте дуже конкретні потреби та не забудете ваші спеціальні привілеї БД.

Сторінка Codex з тих пір оновлюється про те, як це зробити за допомогою прикладів на різних системах та скріншотах. https://codex.wordpress.org/Installing_WordPress#Step_2:_Create_the_Database_and_a_User

Створення імені та користувача Databse (через PHPMyAdmin): https://codex.wordpress.org/Installing_WordPress#Using_phpMyAdmin

Створення імені та користувача Databse (через клієнт командного рядка MySQL): https://codex.wordpress.org/Installing_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