Re: New default role- 'pg_read_all_data'
От | Stephen Frost |
---|---|
Тема | Re: New default role- 'pg_read_all_data' |
Дата | |
Msg-id | 20200828124303.GW29590@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: New default role- 'pg_read_all_data' (Georgios Kokolatos <gkokolatos@protonmail.com>) |
Ответы |
Re: New default role- 'pg_read_all_data'
Re: New default role- 'pg_read_all_data' Re: New default role- 'pg_read_all_data' |
Список | pgsql-hackers |
Greetings, * Georgios Kokolatos (gkokolatos@protonmail.com) wrote: > The patch seems to be implementing a useful and requested feature. > The patch applies cleanly and passes the basic regress tests. Also the commitfest bot is happy. > > A first pass at the code, has not revealed any worthwhile comments. > Please allow me for a second and more thorough pass. The commitfest has hardly started after all. Great, thanks! > Also allow me a series of genuine questions: > > What would the behaviour be with REVOKE? > In a sequence similar to: > GRANT ALL ON ... GRANT ALL would be independently GRANT'ing rights to some role and therefore unrelated. > REVOKE pg_read_all_data FROM ... This would simply REVOKE that role from the user. Privileges independently GRANT'd directly to the user wouldn't be affected. Nor would other role membership. > What privileges would the user be left with? Would it be possible to end up in the same privilege only with a GRANT command? I'm not sure what's being asked here. > Does the above scenario even make sense? I definitely believe it makes sense for a given role/user to be a member of pg_read_all_data and to be a member of other roles, or to have other privileges GRANT'd directly to them. Thanks, Stephen
Вложения
В списке pgsql-hackers по дате отправления: