From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Christian Lehmann <info(at)chlehmann(dot)ch>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Shared postgres-cluster / permissions |
Date: | 2022-03-17 15:29:34 |
Message-ID: | a2175514fcbc8da8cb825051179fc9ee84effefe.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, 2022-03-17 at 11:48 +0100, Christian Lehmann wrote:
> There is a "alter default privileges in schema public" in place which grants ALL
> to the rw-role for new tables and select to the ro-role. but it only does it, if
> the rw-role is creating the table. if the user (for example serviceuser) is creating
> new items, it does not add this default privs. (which is by design, but bad because
> other users won't be able to access the table).
>
> do you have a good way to work around this? is my role-setup "correct" or do you
> have a better idea how to do this? as i understood, there is no possibility to have
> a wildcard-default-privilege-setting, right?
You can run an ALTER DEFAULT PRIVILEGES for each user.
But often it is better to have only one role own the tables. If all roles that may create
tables are members of the rw-role, you can give CREATE on the schema only to that role,
and anybody who wants to create an object has to SET ROLE "rw-role".
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Loles | 2022-03-17 17:43:30 | Which postgres process cleans up deprecated datafiles |
Previous Message | Jayson Hreczuck | 2022-03-17 13:21:18 | Re: Apparently table locks are the key issue to see red flags |