W bazie danych wykonano następujące polecenia dotyczące praw użytkownika adam
GRANT ALL PRIVILEGES ON klienci TO adam REVOKE SELECT, INSERT, UPDATE ON klienci FROM adamPo wykonaniu poleceń użytkownik adam będzie miał prawa do
A. przeglądania tabeli klienci i wstawiania do niej rekordów.
B. usunięcia tabeli lub jej rekordów.
C. tworzenia tabeli klienci i aktualizowania w niej danych.
D. aktualizowania danych i przeglądania tabeli klienci.
Pytanie z egzaminu CKE, czerwiec 2016 (arkusz E.14-X-16.05).
Po wykonaniu tych poleceń adam zachowuje prawa, które nie zostały odebrane drugim poleceniem REVOKE. Najpierw GRANT ALL PRIVILEGES ON klienci TO adam nadaje mu pełny zestaw uprawnień do obiektu klienci, czyli między innymi SELECT, INSERT, UPDATE, DELETE, a w wielu systemach także DROP, ALTER lub podobne uprawnienia administracyjne zależne od konkretnego silnika bazy danych. Potem REVOKE SELECT, INSERT, UPDATE ON klienci FROM adam odbiera tylko trzy wskazane prawa: odczyt danych, dodawanie rekordów i modyfikowanie istniejących rekordów. Nie odbiera natomiast prawa DELETE ani DROP, dlatego użytkownik nadal może usuwać rekordy z tabeli, a jeżeli dane środowisko traktuje DROP jako część nadanych wcześniej uprawnień do tego obiektu, także usunąć samą tabelę. W praktyce to dość niebezpieczna konfiguracja, bo ktoś nie może nawet podejrzeć danych, ale może je skasować. Moim zdaniem dobrze to pokazuje, dlaczego w administracji bazami danych stosuje się zasadę najmniejszych uprawnień: nadajemy tylko to, co jest naprawdę potrzebne, zamiast dawać ALL PRIVILEGES i potem próbować coś odbierać.
W tym zadaniu łatwo pomylić kolejność i znaczenie poleceń GRANT oraz REVOKE. Trzeba czytać je dokładnie tak, jak wykonałby je serwer bazy danych: najpierw nadanie pełnych uprawnień, a dopiero później odebranie wybranych praw. Skoro polecenie REVOKE usuwa SELECT, INSERT i UPDATE, to adam nie będzie mógł przeglądać tabeli klienci, wstawiać do niej rekordów ani aktualizować danych. Dlatego wniosek, że nadal ma prawo do przeglądania albo aktualizowania tabeli, jest sprzeczny z drugim poleceniem. To typowy błąd: ktoś zapamiętuje samo ALL PRIVILEGES i pomija fakt, że część uprawnień została potem cofnięta. Nie należy też zakładać, że możliwość pracy z tabelą oznacza automatycznie możliwość tworzenia tej samej tabeli od nowa. Polecenie dotyczy obiektu klienci i zestawu praw do niego, a nie ogólnego procesu projektowania struktury bazy. Poza tym aktualizacja danych została jawnie odebrana, więc odpowiedź zawierająca UPDATE odpada od razu. Podobnie odczyt SELECT i wstawianie INSERT są wymienione w REVOKE, więc po cofnięciu nie zostają użytkownikowi. Z mojego doświadczenia najbezpieczniej rozwiązywać takie pytania przez zapisanie sobie listy uprawnień po GRANT, a potem skreślenie dokładnie tych, które występują po REVOKE. Zostają prawa niewymienione w cofnięciu, między innymi usuwanie rekordów, czyli DELETE, oraz potencjalnie usunięcie obiektu, czyli DROP, zależnie od systemu bazodanowego i poziomu nadania praw.