PostgreSQL - jak szybko usunąć użytkownika z istniejącymi uprawnieniami

122

Próbuję utworzyć ograniczonych użytkowników bazy danych dla aplikacji, nad którą pracuję, i chcę usunąć użytkownika bazy danych Postgres, którego używam do eksperymentowania. Czy istnieje sposób, aby usunąć użytkownika bez konieczności wcześniejszego ręcznego cofnięcia wszystkich jego praw lub cofnąć wszystkie uprawnienia, które ma użytkownik?

millimoose
źródło

Odpowiedzi:

145

Co powiesz na

DROP USER <username>

W rzeczywistości jest to alias dla DROP ROLE.

Musisz w sposób bezpośredni zrezygnować z wszelkich uprawnień związanych z tym użytkownikiem, a także przenieść jego własność na inne role (lub porzucić obiekt).

Najlepiej to osiągnąć przez

REASSIGN OWNED BY <olduser> TO <newuser>

i

DROP OWNED BY <olduser>

Ten ostatni usunie wszelkie uprawnienia nadane użytkownikowi.

Zobacz dokumentację postgres dla DROP ROLE i bardziej szczegółowy opis tego.


Dodanie:

Najwyraźniej próba usunięcia użytkownika za pomocą poleceń wymienionych tutaj będzie działać tylko wtedy, gdy wykonujesz je będąc połączonym z tą samą bazą danych, z której utworzono oryginalne GRANTS, jak omówiono tutaj:

https://www.postgresql.org/message-id/83894A1821034948BA27FE4DAA47427928F7C29922%40apde03.APD.Satcom.Local

Tim Kane
źródło
11
Robi: CREATE TABLE foo(bar SERIAL); ALTER TABLE foo OWNER TO postgres; CREATE USER testuser; GRANT ALL ON foo TO testuser; DROP USER testuser dał komunikaty o błędach: ERROR: role "testuser" cannot be dropped because some objects depend on it DETAIL: access to table foo. Jednak DROP OWNED BY testuserzałatwił sprawę, najwyraźniej Postgres uważa granty za przedmioty, które można upuszczać.
millimoose
1
Proszę wyjaśnić, @Tim Kane i millimoose: Naprawdę nie chcę, aby oryginalne tabele zostały usunięte, jeśli GRANT SELECT ON FOO TO TESTUSER, a następnie DROP OWNNED BY TESTUSER. Myślę, że mówisz, że DROP OWNED BY tylko upuszcza granty, ale nie upuszcza obiektu, do którego dotacja została przyznana. Poprawny?
Andrew Wolfe
1
Andrew, najlepiej przeczytać dokumentację dla wyjaśnień. DROP OWNED BY usunie tabele należące do tego użytkownika. REASSIGN OWNED BY spowoduje ponowne przypisanie tych tabel do innego użytkownika. Wybierz jeden.
Tim Kane
3
Jeśli martwisz się, że DROP WŁASNY, pobierając zbyt dużo po wykonaniu REPRESIGN OWNED, gdy nadal istnieją uprawnienia, możesz ODZYSKAĆ ​​WSZYSTKO NA WSZYSTKICH [TABELACH | SEKWENCJE | ...] W SCHEMACIE [nazwa schematu] OD [rola]
jla
Rzeczywiście, polecenie DROP OWNED BY jest nieco niejednoznaczne w swoim znaczeniu i skutkach. Musiałem uważnie przeczytać dokument, żeby zrobić to dobrze. Dzięki za posty chłopaki.
Sébastien Clément
49

Zaakceptowana odpowiedź zakończyła się dla mnie błędami podczas próby ponownego PRZYDZIELENIA WŁASNOŚCI PRZEZ lub UPUSZCZENIA WŁASNOŚCI PRZEZ. Pracowały dla mnie:

REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM username;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM username;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public FROM username;
DROP USER username;

Użytkownik może mieć uprawnienia w innych schematach, w takim przypadku będziesz musiał uruchomić odpowiednią linię REVOKE z „public” zastąpionym przez prawidłowy schemat. Aby wyświetlić wszystkie schematy i typy uprawnień dla użytkownika, zmodyfikowałem polecenie \ dp, aby wykonać następujące zapytanie:

SELECT 
  n.nspname as "Schema",
  CASE c.relkind 
    WHEN 'r' THEN 'table' 
    WHEN 'v' THEN 'view' 
    WHEN 'm' THEN 'materialized view' 
    WHEN 'S' THEN 'sequence' 
    WHEN 'f' THEN 'foreign table' 
  END as "Type"
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE pg_catalog.array_to_string(c.relacl, E'\n') LIKE '%username%';

Nie jestem pewien, które typy uprawnień odpowiadają odwołaniu TABEL, SEKWENCJI lub FUNKCJI, ale myślę, że wszystkie należą do jednego z trzech.

Sasha Kondrashov
źródło
12
To też musiałem dodać:REVOKE ALL PRIVILEGES ON DATABASE db_name FROM username;
Wojciech Jakubas
3
Również uprawnienia schematu.
greatvovan
2
Uprawnienia do schematu:revoke USAGE on SCHEMA some_schema from username;
Alphaaa
Próbowałem tego, ale problem nadal występuje w moim przypadku. Wysłałem to jako osobne pytanie na stackoverflow.com/questions/61168608/ ...
Andrus
17

Zwróć również uwagę, jeśli wyraźnie wyraziłeś zgodę:

CONNECT ON DATABASE xxx TO GROUP ,

musisz to odwołać niezależnie od DROP OWNED BY, używając:

REVOKE CONNECT ON DATABASE xxx FROM GROUP

Eric E.
źródło
Wypróbowałem wszystko powyżej i nadal nie działało to dla mnie, dopóki nie przewinąłem trochę dalej, więc teraz zostało mi trochę włosów. Trochę. : D dziękuję !!
Mitch Kent
6

Musiałem dodać jeszcze jedną linię do REVOKE ...

Po bieganiu:

REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM username;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM username;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public FROM username;

Nadal otrzymuję błąd: nazwa użytkownika nie może zostać usunięta, ponieważ niektóre obiekty są od niej zależne SZCZEGÓŁY: uprawnienia dla schematu publiczny

Brakowało mi tego:

REVOKE USAGE ON SCHEMA public FROM username;

Wtedy mogłem zrezygnować z tej roli.

DROP USER username;
CD4
źródło
Może być również konieczne odebranie uprawnień dla 'SCHEMA pg_catalog', jeśli na przykład utworzyłeś użytkownika dla pg_rewind, który ma uprawnienia do funkcji takich jak pg_read_binary_file.
GreenReaper
5

Oto, co w końcu zadziałało:

REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA myschem FROM user_mike;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA myschem FROM user_mike;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA myschem FROM user_mike;
REVOKE ALL PRIVILEGES ON SCHEMA myschem FROM user_mike;
ALTER DEFAULT PRIVILEGES IN SCHEMA myschem REVOKE ALL ON SEQUENCES FROM user_mike;
ALTER DEFAULT PRIVILEGES IN SCHEMA myschem REVOKE ALL ON TABLES FROM user_mike;
ALTER DEFAULT PRIVILEGES IN SCHEMA myschem REVOKE ALL ON FUNCTIONS FROM user_mike;
REVOKE USAGE ON SCHEMA myschem FROM user_mike;
REASSIGN OWNED BY user_mike TO masteruser;
DROP USER user_mike ;
Preti
źródło
2

Nie ma REVOKE ALL PRIVILEGES ON ALL VIEWS, więc skończyłem na:

do $$
DECLARE r record;
begin
  for r in select * from pg_views where schemaname = 'myschem'
  loop
    execute 'revoke all on ' || quote_ident(r.schemaname) ||'.'|| quote_ident(r.viewname) || ' from "XUSER"';
  end loop;
end $$;

i zwykle:

REVOKE ALL PRIVILEGES ON DATABASE mydb FROM "XUSER";
REVOKE ALL PRIVILEGES ON SCHEMA myschem FROM "XUSER";
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA myschem FROM "XUSER";
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA myschem FROM "XUSER";
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA myschem FROM "XUSER";

aby odniosły sukces:

drop role "XUSER";
gavenkoa
źródło
0

W linii poleceń dostępne jest polecenie dropuserupuszczenia użytkownika z postgres.

$ dropuser someuser
SuperNova
źródło
-19

Zmierzyłem się z tym samym problemem i teraz znalazłem sposób na jego rozwiązanie. Najpierw musisz usunąć bazę danych użytkownika, którego chcesz usunąć. Następnie użytkownika można łatwo usunąć.

Utworzyłem użytkownika o nazwie „msf” i przez chwilę walczyłem, aby go usunąć i odtworzyć. Wykonałem poniższe kroki i udało mi się.

1) Usuń bazę danych

dropdb msf

2) upuść użytkownika

dropuser msf

Teraz pomyślnie usunąłem użytkownika.

Meshach Marimuthu
źródło
2
Jest to niewiarygodne podejście typu slash and burn, ponieważ wymagałoby ode mnie odtworzenia schematu bazy danych dla każdej iteracji mojej pracy. (Co wiązało się z posiadaniem szczegółowych uprawnień do istniejącego schematu bazy danych; tj. Najlepiej, jeśli schemat bazy danych pozostanie nietknięty).
millimoose