Re: State of the art re: group default privileges

From: Michael Orlitzky <michael(at)orlitzky(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: State of the art re: group default privileges
Date: 2013-03-20 23:11:09
Message-ID: 514A420D.1020308@orlitzky.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 03/20/2013 06:40 PM, Adrian Klaver wrote:
> On 03/20/2013 03:26 PM, Michael Orlitzky wrote:
>> On 03/20/2013 05:18 PM, Rob Sargent wrote:
>
>>
>> At the moment, everyone's just experimenting. Even with the proper
>> tooling, my blog app shouldn't have to handle the database permissions
>> table-by-table. I should be able to set up sensible defaults.
>>
> CREATE ROLE adrian LOGIN;
> CREATE ROLE ranger LOGIN;
> CREATE ROLE dev_user ROLE;
> GRANT dev_user TO adrian;
> GRANT dev_user TO ranger;
>
> ALTER ROLE adrian IN DATABASE test set role=dev_user;
>
> aklaver(at)panda:~> psql -d test -U adrian
> ...

Thanks, this is extremely close, but doesn't quite nail it: at the end,
what happens if you create a table as ranger? By default, adrian doesn't
have access to it. You could of course do,

ALTER ROLE ranger IN DATABASE test set role=dev_user;

Now everything in the database will be owned by dev_user. But what
happens if we have 100 databases (this is realistic for us), and add a
new developer a year down the road? I have to not only add him to
dev_user, but look through each database, figure out which ones we've
used this trick on, and do,

ALTER ROLE the_new_guy IN DATABASE foo set role=dev_user;

And I can already achieve this result with a pile of scripts. It just
feels half-assed. When I add someone to a group, they should inherit the
permissions of the group. More convenient, way safer.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message W. Matthew Wilson 2013-03-20 23:38:33 How to join table to itself N times?
Previous Message Adrian Klaver 2013-03-20 22:40:58 Re: State of the art re: group default privileges