W bazie danych wykonano następujące polecenia dotyczące praw użytkownika adam
GRANT SELECT, INSERT, UPDATE, DELETE ON klienci TO adam; REVOKE INSERT, UPDATE, DELETE ON klienci FROM adam;Po wykonaniu poleceń użytkownik adam będzie miał prawo wyłącznie do
A. przeglądania tabeli klienci.
B. wstawiania rekordów do tabeli klienci.
C. przeglądania tabeli klienci i usuwania z niej rekordów.
D. aktualizowania danych w tabeli klienci.
Po tych dwóch poleceniach użytkownik adam ma już tylko uprawnienie SELECT do tabeli klienci, czyli może wyłącznie przeglądać jej zawartość. Najpierw polecenie GRANT nadało mu komplet podstawowych praw operowania na rekordach: SELECT do odczytu, INSERT do dodawania, UPDATE do modyfikacji i DELETE do usuwania danych. Potem jednak wykonano REVOKE INSERT, UPDATE, DELETE, więc dokładnie te trzy uprawnienia zostały odebrane. Ważne jest to, że REVOKE nie usuwa automatycznie wszystkich praw do tabeli, tylko te wymienione w poleceniu. SELECT nie został cofnięty, więc zostaje aktywny. W praktyce taki zestaw uprawnień pasuje np. dla pracownika, który ma tylko podglądać dane klientów, ale nie powinien nic dopisywać ani zmieniać. Moim zdaniem to bardzo dobry przykład zasady najmniejszych uprawnień, często stosowanej w administracji bazami danych: użytkownik dostaje tylko to, co jest mu naprawdę potrzebne. W środowisku produkcyjnym warto też regularnie sprawdzać uprawnienia, np. poleceniami typu SHOW GRANTS lub odpowiednimi widokami systemowymi, zależnie od używanego systemu DBMS.
W tym pytaniu łatwo pomylić działanie poleceń GRANT i REVOKE, szczególnie jeśli patrzy się tylko na pierwszą linijkę kodu. Samo GRANT rzeczywiście nadaje adamowi szeroki zakres uprawnień do tabeli klienci: może czytać dane, dodawać rekordy, aktualizować je oraz usuwać. Ale druga instrukcja jest równie ważna, bo REVOKE odbiera wskazane prawa. Skoro cofnięto INSERT, UPDATE i DELETE, to użytkownik nie może już wstawiać nowych rekordów, nie może poprawiać istniejących danych i nie może kasować wierszy z tabeli. Zostaje mu tylko SELECT, bo tego uprawnienia nikt mu nie odebrał. Typowy błąd myślowy polega tu na założeniu, że wcześniejsze GRANT ma większe znaczenie niż późniejsze REVOKE, a w praktyce stan końcowy uprawnień zależy od całej sekwencji wykonanych poleceń. Niepoprawne jest też myślenie, że skoro użytkownik może przeglądać tabelę, to automatycznie może usuwać albo modyfikować rekordy. W SQL są to osobne przywileje i dobrą praktyką administracyjną jest rozdzielanie ich bardzo precyzyjnie. Uprawnienie DELETE dotyczy kasowania rekordów, UPDATE zmiany istniejących wartości, a INSERT dodawania nowych danych. Każde z nich może być przyznane albo odebrane niezależnie. Z mojego doświadczenia, na testach najbezpieczniej jest czytać takie polecenia po kolei i na końcu zapisać sobie, co zostało: SELECT zostaje, INSERT znika, UPDATE znika, DELETE znika. I wtedy odpowiedź wychodzi bez zgadywania.