Użytkownik bazy danych MySQL: Jakie uprawnienia są potrzebne?


52

Krótka instrukcja instalacji dla WordPress ( „5 minut” ) stwierdza, że:

Utwórz bazę danych WordPress na swoim serwerze internetowym, a także użytkownika MySQL, który ma wszystkie uprawnienia do dostępu i modyfikowania go.

Podczas profesjonalnego zakładania nowego bloga zastanawiałem się, jak to odwzorowuje to, co oferuje mi konfiguracja uprawnień / uprawnień użytkownika bazy danych MySQL:

  • Dane: SELECT , INSERT, UPDATE,DELETE
  • Definicja: CREATE , ALTER,DROP
  • Dodatkowy: INDEX
  • Więcej:
    1. LOCK TABLES
    2. REFERENCES
    3. CREATE TEMPORARY TABLES
    4. CREATE VIEW
    5. SHOW VIEW
    6. CREATE ROUTINE
    7. EXECUTE
    8. ALTER ROUTINE

Jestem prawie pewien, że pierwsze trzy grupy nadałem im nazwę Dane, Definicja i Dodatkowe. Ale co z pozostałymi poniżej wpisu Więcej ? Zwykle powiedziałbym, że nie są potrzebne, ale chciałbym uzyskać drugą opinię.

Odpowiedzi:


13

Inne nie są potrzebne, jak wskazałeś.

Btw, co możesz zrobić, to warunkowo ustawić użytkownika / przepustkę na podstawie żądanej strony. Podobnie jak w przypadku nieuprzywilejowanego wyboru / wstawiania / aktualizacji / usuwania do normalnego użytkowania oraz uprzywilejowanego w zakresie funkcji związanych z definicją / indeksem podczas odwiedzania strony aktualizacji.


1
Czy jest jakieś odniesienie do tego, jak warunkowo ustawić użytkownika / przepustkę na podstawie żądanej strony w środowisku WordPress? TA
superjos

@superjos: Nie wiem, że jestem z góry na głowie, ale istotą tego jest zdefiniowanie zwykłego użytkownika DB: wybierz / wstaw / aktualizuj / usuń w wp-config i, gdy adres URL pasuje do odpowiedniego / strony wp-admin (prawdopodobnie uaktualnij, aktywuj motyw i aktywuj wtyczkę), aby zdefiniować alternatywnego użytkownika, który może zrobić wszystko inne.
Denis de Bernardy

34

„Wszystkie uprawnienia” zwykle oznaczają, że powinieneś udostępnić wszystko użytkownikowi. Jednak ...

Znalazłem co najmniej jeden artykuł, który twierdzi, że użytkownik MySQL potrzebuje tylko:

  • WYBIERZ
  • WSTAWIĆ
  • AKTUALIZACJA

Wnikając głębiej , odkryłem, że aby w pełni działać (automatyczne aktualizacje, instalacja / dezinstalacja wtyczki itp.), WordPress wymaga dodatkowych uprawnień:

  • USUNĄĆ
  • ALTER (do aktualizacji)
  • UTWÓRZ TABELĘ
  • TABELA UPADKU

Poza tym nie ma odniesienia, ale ma to sens:

  • INDEKS

Ale to jedyne dwa solidne odniesienia, które mogę znaleźć, które są poparte opiniami zamieszczonymi gdzie indziej. Nadal zachęcam do trzymania się GRANT ALL, ale jeśli absolutnie musisz ograniczyć użycie DB, zacznij od tych 7 uprawnień i przetestuj w pełni, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami.


Dziękujemy za podzielenie się swoimi przemyśleniami. W przypadku tej zainstalowanej strony NIE UDZIELAŁEM WSZYSTKICH, ponieważ nie jest to strona programistyczna i zamiast tego trzymam się wszystkich. INDEKS. Wygląda dobrze do tej pory, myślę, że śledzę to przez kolejne dni, to jest strona z prawdziwego życia, w tym. dużo użycia wtyczek i tym podobne. W przypadku INDEKSU mogę również trochę przeszukać rdzeń i instrukcję mysql.
hakre

1
Pamiętaj tylko, że wtyczki innych firm mogą wywoływać dowolne instrukcje SQL, które chcą ... więc upewnij się, że odpowiednio je zweryfikowałeś przed zainstalowaniem rzeczy zależnych od przywilejów, które odebrałeś.
EAMann

12

Oto, co Codex ma do powiedzenia na temat ograniczania uprawnień użytkownika bazy danych:

Do normalnych operacji WordPress, takich jak publikowanie postów na blogu, przesyłanie plików multimedialnych, publikowanie komentarzy, tworzenie nowych użytkowników WordPress i instalowanie wtyczek WordPress, użytkownik bazy danych MySQL potrzebuje tylko uprawnień do odczytu i zapisu danych do bazy danych MySQL; WYBIERZ, WSTAW, AKTUALIZUJ i USUŃ.

Dlatego wszelkie inne struktury bazy danych i uprawnienia administracyjne, takie jak DROP, ALTER i GRANT, mogą zostać cofnięte. Cofając takie przywileje, poprawiasz również zasady ograniczania.

Uwaga: niektóre wtyczki, motywy i główne aktualizacje WordPress mogą wymagać wprowadzenia zmian strukturalnych w bazie danych, takich jak dodanie nowych tabel lub zmiana schematu. W takim przypadku przed zainstalowaniem wtyczki lub aktualizacją oprogramowania tymczasowo zezwól użytkownikowi bazy danych na wymagane uprawnienia.

http://codex.wordpress.org/Hardening_WordPress


2
Kiedy tylko jest to możliwe, staram się praktykować zasadę najmniejszego przywileju. (Przydatne) cytowane informacje nie są już w linkowanym artykule Kodeksu, więc dziękuję za skopiowanie ich tutaj.
Anthony G - sprawiedliwość dla Moniki

2

Jeśli chodzi o „notatkę” w poście redburn, Wordpress Codex ma również Ostrzeżenie, które powinieneś przeczytać również o aktualizacjach i zmianach schematu bazy danych ...

(Edycja: Zauważyłem jednak, że NIE WIDUJĘ „GRANT” na liście uprawnień podczas tworzenia lub aktualizacji użytkownika. Być może należy dodać „CREATE” do listy? Czy ktoś ma informacje na ten temat? - używając Hostgator cPanel , Marzec 2016 r. -)

OSTRZEŻENIE:
Próba aktualizacji bez tych uprawnień [ WYBIERZ, WSTAW, AKTUALIZUJ, USUŃ, UPUŚĆ, ZMIEŃ i UDZIELIĆ] może powodować problemy w przypadku zmiany schematu bazy danych. Dlatego NIE zaleca się cofania tych uprawnień. Jeśli uważasz, że musisz to zrobić ze względów bezpieczeństwa, upewnij się, że najpierw masz solidny plan tworzenia kopii zapasowych, a regularne kopie zapasowe całej testowanej kopii są prawidłowe i można je łatwo przywrócić. Nieudane uaktualnienie bazy danych zwykle można rozwiązać, przywracając bazę danych z powrotem do starej wersji, udzielając odpowiednich uprawnień, a następnie pozwalając WordPress ponownie spróbować zaktualizować bazę danych. Przywrócenie bazy danych przywróci ją do poprzedniej wersji, a ekrany administracyjne WordPress wykryją starą wersję i umożliwią uruchomienie na niej niezbędnych poleceń SQL. Większość aktualizacji WordPress nie zmienia schematu, ale niektóre tak. Tylko główne ulepszenia punktów (od 3,7 do 3,8, na przykład) zmieni schemat. Drobne ulepszenia (3.8 do 3.8.1) zazwyczaj nie będą. Niemniej jednak regularnie wykonuj kopię zapasową.

Kodeks: http://codex.wordpress.org/Hardening_WordPress


0

Moja opinia jest taka sama jak powyżej @EAMann, a także źródła, do których się odwoływał: GRANT ALL jest niezbędny, aby zapewnić funkcjonalność i bezpieczeństwo witryny. Nawet w zakładzie produkcyjnym powinieneś spróbować trzymać się instrukcji obsługi.

Jako ktoś, kto wnosi kod do rdzenia WordPress i kilku wtyczek, zalecam zachowanie domyślnych uprawnień do DB, zgodnie z sugestią zawartą w instrukcji użytkownika (UDZIEL WSZYSTKICH UPRAWNIEŃ NA wpdatabasename. * TO „wordpressusername” @ „nazwa hosta”).

Kod źródłowy WordPress (zarówno obecny, jak i przyszły) zakłada, że ​​użytkownik DB WordPress ma wszystkie uprawnienia DB dla danej bazy danych WordPress. Jeśli w konfiguracji brakuje jakichkolwiek uprawnień DB, możesz napotkać problemy podczas aktualizacji WordPressa i dodawania kolejnych wtyczek.

Tak więc naprawdę nie powinieneś używać uprawnień DB innych niż domyślne uprawnienia DB zalecane w instrukcji, chyba że wiesz, co robisz, masz bardzo specyficzne potrzeby i nie zapomnisz, że masz niestandardowe uprawnienia DB.

Od tego czasu strona Kodeksu została zaktualizowana o tym, jak to zrobić za pomocą przykładów na różnych systemach i zrzutach ekranu. https://codex.wordpress.org/Installing_WordPress#Step_2:_Create_the_Database_and_a_User

Tworzenie nazwy i użytkownika bazy danych (przez PHPMyAdmin): https://codex.wordpress.org/Installing_WordPress#Using_phpMyAdmin

Tworzenie nazwy i użytkownika bazy danych (za pomocą klienta wiersza poleceń 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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.