Thread: Separate DDL and SQL users
Hello All,
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?
Previously I've always set the owner on tables etc to 'postgres' so that it's not bound to any special user.
Any suggestions?
Thanks,
Rob
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?
Previously I've always set the owner on tables etc to 'postgres' so that it's not bound to any special user.
Any suggestions?
Thanks,
Rob
Phone: 0800 021 0888 Email: contactus@
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63
Hi Rob,
- Does this helps?
THE RE_MIGRATION_ROLE
=====================
# Creating the role
## Create the role with your permissions
CREATE ROLE re_migration WITH optional_permissions;## Grant role ALL permissions in the database migration
GRANT ALL ON migration TO re_migration;
GRANT ALL ON migration TO re_migration;
## Make everyone in this role to automaticaly have all the role's privileges
ALTER ROLE re_migration INHERIT;
ALTER ROLE re_migration INHERIT;
## Create the user
CREATE USER migration_user1 ....;
GRANT re_migration TO migration_user1;
THE LIVE_APPLICATION_ROLE
=========================
# Creating the role
## Create the role with your permissions
CREATE ROLE live_application WITH optional_permissions;
CREATE ROLE live_application WITH optional_permissions;
## Grant role SELECT, INSERT, UPDATE, DELETE permissions in the database migration
GRANT SELECT, INSERT, UPDATE, DELETE ON migration TO live_application;
GRANT SELECT, INSERT, UPDATE, DELETE ON migration TO live_application;
## Make everyone in this role to automaticaly have all the role's privileges
ALTER ROLE live_application INHERIT;
ALTER ROLE live_application INHERIT;
## Create the user
CREATE USER live_app_user1 ....;
GRANT live_application TO live_app_user1;
Regards,
--
Helio Campos Mello de Andrade http://training.linuxfoundation.org/certification/verify-linux-certifications (ID: LFCS-1500-0312-0100, Last name: Andrade)
2016-03-11 8:18 GMT-03:00 Rob Emery <re-pgsql@codeweavers.net>:
Hello All,
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?
Previously I've always set the owner on tables etc to 'postgres' so that it's not bound to any special user.
Any suggestions?
Thanks,
RobPhone: 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
What about using schemas:
CREATE SCHEMA migrations;
GRANT CREATE, USAGE ON SCHEMA migration TO re_migration WITH GRANT OPTION;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA migration TO live_application;
- The difference between databases and schemas in postgres are few. (you can't execute queries between databases but you can do it between schemas).
Paz,
--
Helio Campos Mello de Andrade http://training.linuxfoundation.org/certification/verify-linux-certifications (ID: LFCS-1500-0312-0100, Last name: Andrade)
2016-03-11 9:25 GMT-03:00 Robert Emery <robertemery@codeweavers.net>:
Hi Helio,
I've tried something similar however, I believe what you're suggesting
only works on a single table if I under stand correctly? for example:
GRANT SELECT, INSERT, UPDATE, DELETE ON migration TO live_application;
fails with the error:
ERROR: relation "migration" does not exist
SQL state: 42P01> http://training.linuxfoundation.org/certification/verify-linux-certifications
On 11/03/2016, Helio Campos Mello de Andrade <helio.campos@gmail.com> wrote:
> Hi Rob,
>
> - Does this helps?
>
> THE RE_MIGRATION_ROLE
> =====================
>
> # Creating the role
> ## Create the role with your permissions
> CREATE ROLE re_migration WITH optional_permissions;
> ## Grant role ALL permissions in the database migration
> GRANT ALL ON migration TO re_migration;
> ## Make everyone in this role to automaticaly have all the role's
> privileges
> ALTER ROLE re_migration INHERIT;
>
> ## Create the user
> CREATE USER migration_user1 ....;
> GRANT re_migration TO migration_user1;
>
> THE LIVE_APPLICATION_ROLE
> =========================
>
> # Creating the role
> ## Create the role with your permissions
> CREATE ROLE live_application WITH optional_permissions;
> ## Grant role SELECT, INSERT, UPDATE, DELETE permissions in the database
> migration
> GRANT SELECT, INSERT, UPDATE, DELETE ON migration TO live_application;
> ## Make everyone in this role to automaticaly have all the role's
> privileges
> ALTER ROLE live_application INHERIT;
>
> ## Create the user
> CREATE USER live_app_user1 ....;
> GRANT live_application TO live_app_user1;
>
> Regards,
>
> --
> Helio Campos Mello de Andrade
>
> (ID: LFCS-1500-0312-0100, Last name: Andrade)
> http://www.expertrating.com/reports/transcript.aspx?transcriptid=1608144
> http://www.expertrating.com/reports/transcript.aspx?transcriptid=2962390
>
> 2016-03-11 8:18 GMT-03:00 Rob Emery <re-pgsql@codeweavers.net>:
>
>> Hello All,
>>
>> 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?
>>
>> Previously I've always set the owner on tables etc to 'postgres' so that
>> it's not bound to any special user.
>>
>> Any suggestions?
>>
>> Thanks,
>> Rob
>>
>> <https://www.codeweavers.net>
>>
>>
>> <http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=http%3A%2F%2Fus6.campaign-archive1.com%2F%3Fu%3Ddb934935d4174e46e9063c8c4%26id%3De34a33f79a&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
>> Codeweavers
>>
>> March
>> Newsletter
>> <http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=http%3A%2F%2Fus6.campaign-archive2.com%2F%3Fu%3Ddb934935d4174e46e9063c8c4%26id%3D8939a8a212&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
>>
>> <http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=http%3A%2F%2Fus6.campaign-archive2.com%2F%3Fu%3Ddb934935d4174e46e9063c8c4%26id%3D8939a8a212&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
>> l
>>
>> *Codeweavers' Digital Marketing Conference
>> <http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=https%3A%2F%2Fcodeweavers.net%2Fcodeweavers-digital-marketing-conference&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>*
>>
>> The launch of the stats that will help you sell more cars
>> <http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=https%3A%2F%2Fcodeweavers.net%2Fcompany-blog%2Fthe-launch-of-the-stats-that-will-help-you-sell-more-cars&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
>>
>> *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
>>
>> <https://www.linkedin.com/company/codeweavers-limited>
>> <https://vimeo.com/codeweaversltd>
>> <https://plus.google.com/b/105942302039373248738/+CodeweaversNet/posts>
>> <https://twitter.com/CodeweaversTeam?lang=en-gb>
>>
>
--
Robert Emery
Infrastructure Director
E: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net
--
<https://www.codeweavers.net>
<http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=http%3A%2F%2Fus6.campaign-archive1.com%2F%3Fu%3Ddb934935d4174e46e9063c8c4%26id%3De34a33f79a&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
Codeweavers
March
Newsletter
<http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=http%3A%2F%2Fus6.campaign-archive2.com%2F%3Fu%3Ddb934935d4174e46e9063c8c4%26id%3D8939a8a212&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
<http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=http%3A%2F%2Fus6.campaign-archive2.com%2F%3Fu%3Ddb934935d4174e46e9063c8c4%26id%3D8939a8a212&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0> l
*Codeweavers' Digital Marketing Conference
<http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=https%3A%2F%2Fcodeweavers.net%2Fcodeweavers-digital-marketing-conference&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>*
The launch of the stats that will help you sell more cars
<http://t.sidekickopen42.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XX4QBhKzW64Js984WrKTYVd0r_-56dzZCf1d8gHj02?t=https%3A%2F%2Fcodeweavers.net%2Fcompany-blog%2Fthe-launch-of-the-stats-that-will-help-you-sell-more-cars&si=4882959321006080&pi=04b7a1ae-3680-4ca6-d2bb-74bc3d2d6fc0>
*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
<https://www.linkedin.com/company/codeweavers-limited>
<https://vimeo.com/codeweaversltd>
<https://plus.google.com/b/105942302039373248738/+CodeweaversNet/posts>
<https://twitter.com/CodeweaversTeam?lang=en-gb>
Hi Thomas
That sounds actually ideal; I can create the schema as a superuser and switch the owner to re_migration.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.
ALTER DEFAULT PRIVILEGES
FOR ROLE re_migration
IN SCHEMA new_schema
GRANT SELECT ON TABLES TO live_application;
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
Phone: 0800 021 0888 Email: contactus@
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63
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:
RobThanks,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?Although when I switched it to :From your suggestion, I've actually just tried that, and I was finding that doing:Hi ThomasThat sounds actually ideal; I can create the schema as a superuser and switch the owner to re_migration.
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.
ALTER DEFAULT PRIVILEGES
FOR ROLE re_migration
IN SCHEMA new_schema
GRANT SELECT ON TABLES TO live_application;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.http://www.postgresql.org/mailpref/pgsql-admin
Thomas
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
--Robert Emery
Infrastructure Director
E: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.netPhone: 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
Hi Keith,
Ah! That makes a lot more sense, thanks for the clarification; we've done exactly the same now, we use one user for all schema changes who owns the db and has its default permissions set to grant as appropriate over the tables for the live applications.On 11 March 2016 at 15:05, Keith <keith@keithf4.com> wrote:
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.KeithOn Fri, Mar 11, 2016 at 9:27 AM, Rob Emery <re-pgsql@codeweavers.net> wrote:RobThanks,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?Although when I switched it to :From your suggestion, I've actually just tried that, and I was finding that doing:Hi ThomasThat sounds actually ideal; I can create the schema as a superuser and switch the owner to re_migration.
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.
ALTER DEFAULT PRIVILEGES
FOR ROLE re_migration
IN SCHEMA new_schema
GRANT SELECT ON TABLES TO live_application;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.http://www.postgresql.org/mailpref/pgsql-admin
Thomas
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
--Robert Emery
Infrastructure Director
E: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.netPhone: 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
--
Robert Emery
Infrastructure Director
E: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net
Infrastructure Director
E: robertemery@codeweavers.net | T: 01785 711633 | W: www.codeweavers.net
Phone: 0800 021 0888 Email: contactus@
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63
Codeweavers Ltd | Barn 4 | Dunston Business Village | Dunston | ST18 9AB
Registered in England and Wales No. 04092394 | VAT registration no. 974 9705 63