Re: New default role- 'pg_read_all_data'

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Georgios Kokolatos <gkokolatos(at)protonmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: New default role- 'pg_read_all_data'
Date: 2020-08-28 12:43:03
Message-ID: 20200828124303.GW29590@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Georgios Kokolatos (gkokolatos(at)protonmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2020-08-28 12:43:52 Re: Handing off SLRU fsyncs to the checkpointer
Previous Message Stephen Frost 2020-08-28 12:38:48 Re: New default role- 'pg_read_all_data'