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.
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 |