Re: Separate DDL and SQL users

No, it's working as expected. ALTER DEFAULT PRIVILEGES doesn't change the default privileges for every object created by anyone in a given schema. It changes the default privileges for objects created by a given role. If you don't give a role, then the default privileges are changed for the role that's currently logged in.

We've managed this by having all DDL (object creation and maintenance) done by a specific role. We usually make that role the owner of everything as well.

Keith

On Fri, Mar 11, 2016 at 9:27 AM, Rob Emery <re-pgsql@codeweavers.net> wrote:

Hi Thomas

That sounds actually ideal; I can create the schema as a superuser and switch the owner to re_migration.

From your suggestion, I've actually just tried that, and I was finding that doing:

ALTER DEFAULT PRIVILEGES
IN SCHEMA new_schema
GRANT SELECT ON TABLES TO live_application;

didn't seem to work, a table when created wasn't readable by live_application.

Although when I switched it to :

ALTER DEFAULT PRIVILEGES
FOR ROLE re_migration
IN SCHEMA new_schema
GRANT SELECT ON TABLES TO live_application;

it seemed to work!? This feels really odd to me, I'd expect the first one to apply to everyone. Unless I'm totally misinterpreting that behaviour?

Thanks,

Rob

On 11 March 2016 at 13:08, Thomas Kellerer <spam_eater@gmx.net> wrote:

Rob Emery schrieb am 11.03.2016 um 12:18:
> So we're looking at automating our migrations against PG for the
> developers so that it's simple enough for them and no maintenance for
> me. I'm struggling to find a role/permissions structure that works;
> we've come from SQL Server so we're used to having DBRoles.
>
> So I want the re_migration role to be able to create tables,
> sequences etc and grant to other users etc; yet I want the
> live_application role to be able to select,insert,update,delete.
>
> It seems that the only real solution here is to have the db owned by
> re_migration, then in every migration GRANT
> SELECT,INSERT,UPDATE,DELETE to the live_application role?

You can set default privileges for a schema: http://www.postgresql.org/docs/current/static/sql-alterdefaultprivileges.html

If you do that, every object that is created in the schema is automatically assigned those default privileges.

So you only need to do do once, after you create a new schema, e.g.

as re_migration do:

  create schema dbo;
  grant usage on dbo to life_application;
  alter default privileges in schema dbo grant select,insert,update,delete on tables to live_application;
  alter default privileges in schema dbo grant usage,select,update on sequences to live_application;

Of course the re_migration role needs to have the privileges to create a schema.

Thomas




--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:

http://www.postgresql.org/mailpref/pgsql-admin

--

Robert Emery
Infrastructure Director

E: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net

Codeweavers 

​

March

 Newsletter

 l 

Codeweavers' Digital Marketing Conference

The launch of the stats that will help you sell more cars

Phone: 0800 021 0888   Email: contactus@codeweavers.net
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63