W tabeli artykuly wykonano następujące polecenia dotyczące praw użytkownika jan
GRANT ALL PRIVILEGES ON artykuly TO jan REVOKE SELECT, UPDATE ON artykuly FROM janPo wykonaniu poleceń użytkownik jan będzie miał prawa do
A. aktualizowania danych i przeglądania tabeli.
B. tworzenia tabeli i aktualizowania w niej danych.
C. tworzenia tabeli i wypełniania jej danymi.
D. przeglądania tabeli.
Pytanie z egzaminu CKE, październik 2016 (arkusz E.14-X-16.08).
Po tych dwóch poleceniach użytkownik jan nie ma już pełnego zestawu praw, mimo że na początku dostał ALL PRIVILEGES. Najpierw instrukcja GRANT ALL PRIVILEGES ON artykuly TO jan nadaje mu komplet dostępnych uprawnień do obiektu artykuly. Potem REVOKE SELECT, UPDATE ON artykuly FROM jan odbiera dokładnie dwa wskazane prawa: SELECT, czyli przeglądanie danych, oraz UPDATE, czyli modyfikowanie istniejących rekordów. Zostają więc inne uprawnienia z pakietu ALL, między innymi CREATE oraz INSERT, co w odpowiedzi opisano jako tworzenie tabeli i wypełnianie jej danymi. W praktyce INSERT pozwala dodawać nowe rekordy, np. dopisywać artykuły do tabeli, ale bez SELECT użytkownik może nie móc ich potem normalnie podejrzeć. To jest dość ważne w administracji bazami: GRANT nadaje, REVOKE odbiera, a końcowy stan uprawnień wynika z obu poleceń razem, nie tylko z ostatniego. Moim zdaniem warto zawsze czytać takie zadania chronologicznie, bo wtedy mniej łatwo pomylić aktualizowanie danych z ich dodawaniem. W dobrych praktykach administracyjnych stosuje się zasadę najmniejszych uprawnień, czyli użytkownik dostaje tylko to, co faktycznie jest mu potrzebne do pracy.
W tym zadaniu najczęstszy błąd polega na tym, że ktoś widzi GRANT ALL PRIVILEGES i zapamiętuje tylko pierwszą linijkę, a pomija działanie REVOKE. To prowadzi do wniosku, że jan nadal może robić wszystko, w tym przeglądać i aktualizować dane. Tak jednak nie jest, bo REVOKE działa jak cofnięcie konkretnych uprawnień. Skoro odebrano SELECT, użytkownik nie powinien mieć prawa do przeglądania tabeli. Skoro odebrano UPDATE, nie powinien też móc aktualizować istniejących rekordów. Dlatego odpowiedzi mówiące o aktualizowaniu danych albo przeglądaniu tabeli nie pasują do końcowego stanu praw. Trzeba też rozróżniać UPDATE od INSERT. UPDATE zmienia rekordy, które już są w tabeli, a INSERT dodaje nowe rekordy, czyli potocznie wypełnia tabelę danymi. To są dwa różne przywileje SQL i w administracji baz danych ma to duże znaczenie. Można komuś pozwolić dopisywać nowe wpisy, ale nie pozwolić poprawiać starych, na przykład w systemie zgłoszeń albo dzienniku zdarzeń. Podobnie SELECT nie jest automatycznie potrzebny do każdego innego działania, choć w praktyce wiele aplikacji go wymaga do wygodnej pracy. Z mojego doświadczenia najlepiej przy takich pytaniach wypisać sobie stan po kolei: najpierw pełne prawa, potem usunięcie SELECT i UPDATE, a dopiero potem patrzeć, które odpowiedzi zostały. Wtedy widać, że zostają prawa typu CREATE i INSERT, a nie przeglądanie czy aktualizacja.