Заключване на публична групова роля в PostgreSQL

Въз основа на информацията, която четох за привилегиите, научих, че е добре да се отнемат привилегии, преди да се присвоят каквито и да е привилегии на роли. Имах 1 потребител, с когото работех, наречен appuser и направих следното:

REVOKE ALL PRIVILEGES ON SCHEMA PUBLIC FROM GROUP PUBLIC;

GRANT SELECT
  ON public.table1 TO appuser;

GRANT SELECT
  ON public.table1_id_seq TO appuser;

GRANT SELECT
  ON public.table2 TO appuser;

GRANT SELECT
  ON public.table2_id_seq TO appuser;

Направих това с надеждата да премахна всички привилегии, прикрепени към всички новодобавени потребители, които автоматично са част от членството в публична роля. Вместо това получих грешка в резултат на appuser няма разрешения за схемата. Това обаче е моето неразбиране с тази грешка. 1. PgAdminIII не показва публична роля под Групови роли за тази схема 2. appuser не изглежда да е член на група, наречена public (защото не съществува в интерфейса). 3. привилегиите на appuser са изрично предоставени, дори и да са част от публичната роля

И така... има ли някаква подразбираща се групова роля, наречена „Публичен“, която засяга привилегиите на този потребител? Не разбирам какво става. Също така се опитах да намеря къде да покажа членството в груповата роля от командния ред pgAdminIII, но и там не успях. Между другото, за да го поправя, просто обърнах първата команда (т.е. ПРЕДОСТАВЯНЕ НА ВСИЧКИ ПРИВИЛЕГИИ НА СХЕМА ПУБЛИЧНО НА ГРУПА ПУБЛИЧНО); Това обаче основно отменя това, което първоначално се опитвах да направя (т.е. просто да заключа масите).

Някакви идеи?

Актуализация: Имам предчувствие, открих какъв може да е проблемът. Не мисля, че appuser има разрешения за схемата. Ако не греша, разрешенията за схемата трябва да бъдат предоставени, преди да може да се получи достъп до обекти под схемата.


person Guest Posting    schedule 05.12.2013    source източник
comment
Защо не сте предоставили разрешения на appuser в схемата, ако грешката казва, че ролята няма разрешения за схемата? Все пак вие ги отменихте за всички и не ги давате на никого.   -  person Milen A. Radev    schedule 06.12.2013
comment
Трябва да покажете точните команди, които сте изпълнявали, и точните грешки, които сте получавали, а не наративни обяснения за тях.   -  person Peter Eisentraut    schedule 06.12.2013
comment
@ Милен - Мисля, че ударихте ноктите на главата. Какъв шамар по челото. Ще тествам това сутринта.   -  person Guest Posting    schedule 06.12.2013
comment
@Peter - всъщност бях в процес на търсене на командите, след като публикувах това. Тъй като това е процес на миграция, който наследих, все още научавам къде са всички части. Ще публикувам актуализация, след като направя още малко проучване.   -  person Guest Posting    schedule 06.12.2013


Отговори (1)


Добре, така че отговорът тук е доста сложен относно това защо нещата се държат по начина, по който се държат и вероятно си струва да обсъдим до известна степен модела за сигурност на PostgreSQL.

PUBLIC не е роля или група, а по-скоро запазена дума. Начинът, по който работят разрешенията, е, че се прилага достъпът, предоставен на текущите наследени роли или PUBLIC. Всъщност бях ухапан от това в миналото, докато изграждах рамки, които обгръщат ролите на PostgreSQL.

Като цяло моето мнение е, че искате да направите следното:

  1. Не позволявайте на всички да влизат в db.

    REVOKE CONNECT ON DATABASE mydb FROM public;
    
  2. Вие можете да искате да отмените достъпа до схеми и таблици и от обществеността.

  3. Това, което мисля, че сте направили, е нещо друго, което е да отмените разрешенията от схемата (но не и таблиците в схемата!) и следователно да запазите ПУБЛИЧЕН достъп за разрешения по подразбиране до таблици в тази схема. Това може или не може да е това, което искате. Във всеки случай, както разбрахте, трябва да добавите обратно разрешения към схемата, за да се върнете там, където сте.

Сега не съм напълно сигурен какво се опитвате да направите тук. Ако искате напълно да заключите своя db, трябва да направите същото и за всички таблици. В противен случай, ако:

 CREATE USER foo;
 GRANT USAGE ON SCHEMA PUBLIC TO foo;

Тогава foo ще има достъп до всички разрешения, които PUBLIC има за масите.

person Chris Travers    schedule 23.12.2013