Poprawna komenda do odebrania uprawnień użytkownikowi w MySQL to REVOKE i warto ją sobie dobrze zakodować w głowie, bo w administracji bazą używa się jej naprawdę często. Składnia w najprostszym wariancie wygląda np. tak: REVOKE SELECT, INSERT ON baza.tabela FROM 'user'@'localhost'; – tutaj odbierasz konkretne prawa (SELECT, INSERT) do wskazanej tabeli danemu użytkownikowi. Można też odebrać wszystkie uprawnienia: REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'user'@'localhost';, co jest przydatne, gdy chcesz „odciąć” konto od bazy, ale jeszcze go nie usuwać. Z mojego doświadczenia lepiej jest właśnie ograniczać i porządkować uprawnienia, niż od razu kasować użytkowników, bo często wracasz do tych kont np. w środowisku testowym. W MySQL cały mechanizm praw opiera się na parze GRANT/REVOKE: GRANT nadaje uprawnienia, REVOKE je odbiera. To jest zgodne z dobrymi praktykami bezpieczeństwa – minimalny dostęp, tylko tyle, ile jest faktycznie potrzebne (zasada least privilege). W realnych projektach webowych np. aplikacja PHP powinna mieć konto w MySQL z ściśle ograniczonym zakresem operacji, a gdy zmienia się rola aplikacji, zamiast tworzyć nowe konto „na pałę”, lepiej doprecyzować lub cofnąć stare uprawnienia właśnie przez REVOKE. Warto też pamiętać, że po większych zmianach praw dobrze jest wykonać FLUSH PRIVILEGES w starszych wersjach MySQL lub po modyfikacjach bezpośrednio w tabelach systemowych, chociaż standardowo przy GRANT/REVOKE nie jest to już konieczne. Moim zdaniem opanowanie REVOKE to podstawa świadomej administracji serwerem bazodanowym, szczególnie gdy mówimy o środowiskach produkcyjnych, gdzie każdy nadmiarowy przywilej może być potencjalnym zagrożeniem.
W MySQL zarządzanie uprawnieniami użytkowników opiera się na dość precyzyjnym zestawie poleceń i łatwo się tu pomylić, jeśli kojarzymy nazwy komend tylko „na czuja”. Wiele osób słusznie kojarzy GRANT z uprawnieniami i wyciąga z tego pochopny wniosek, że tą samą komendą można też prawa odbierać. W rzeczywistości GRANT służy wyłącznie do nadawania przywilejów, np. GRANT SELECT, INSERT ON baza.* TO 'user'@'localhost';. To jest kierunek „do przodu”: dajemy dostęp. Cofanie wymaga osobnego, odwrotnego polecenia, czyli REVOKE. Próba „odebrania” praw przez GRANT po prostu niczego nie cofnie, co najwyżej nadpisze lub doda kolejne uprawnienia. Drugi typ błędnego skojarzenia dotyczy CREATE. To polecenie odpowiada za tworzenie obiektów w bazie: CREATE DATABASE, CREATE TABLE, CREATE USER itd. Może się wydawać, że skoro CREATE USER tworzy użytkownika, to może istnieje też jakaś opcja CREATE do manipulowania uprawnieniami, ale to myślenie jest trochę życzeniowe. CREATE nie zarządza prawami, tylko strukturą i kontami. Jeśli chcesz odebrać użytkownikowi dostęp, to nie tworzysz nic nowego, tylko modyfikujesz to, co już istnieje, właśnie przez REVOKE lub w ostateczności DROP USER. Odpowiedź z RENAME również bywa myląca. Istnieje komenda RENAME TABLE czy RENAME USER, ale jej rola to jedynie zmiana nazwy obiektu lub konta, bez ingerencji w zakres jego uprawnień. Użytkownik po zmianie nazwy zachowuje swoje przywileje, więc nie jest to żadne odebranie praw, tylko kosmetyka administracyjna. Typowy błąd myślowy przy takich pytaniach polega na tym, że szuka się „znajomo brzmiącej” komendy i dopowiada sobie znaczenie. W SQL, szczególnie w kontekście bezpieczeństwa, nazwy są dość konsekwentne: GRANT – daj, REVOKE – odbierz, CREATE – utwórz, RENAME – zmień nazwę. Znajomość tych podstawowych par przeciwstawnych operacji jest kluczowa przy profesjonalnej administracji serwerem baz danych, bo pomyłka może zostawić użytkownikowi zbyt szerokie uprawnienia albo w ogóle nie zadziałać tak, jak się spodziewasz.