Postgresql – Permissions on Schemas to Groups

The documentation about ALTER DEFAULT PRIVILEGES tells you a possible reason - it is not that clearly described, though.

Let's see, what is said:

You can change default privileges only for objects that will be created by yourself or by roles that you are a member of.

This means that the default privileges defined by this statement applies only to objects that are created by you (or the role you are a member of). Let's see this in action!

alice's schema

First, we are logged in as alice. Then, in a newly created schema, we create a table and grant some rights to bob:

SELECT current_user;
 current_user 
──────────────
 alice


SHOW search_path ;
 search_path  
──────────────
 test, public

CREATE SCHEMA alicetest;

ALTER DEFAULT PRIVILEGES 
    FOR ROLE alice 
    IN SCHEMA alicetest 
    GRANT ALL ON TABLES TO alice;

GRANT SELECT ON alicetest.a TO bob; 
-- this I do only for showing the privileges - 
-- the owner has by default ALL and is not shown by \dp

\dp alicetest.a
                             Access privileges
  Schema   │ Name │ Type  │  Access privileges  │ Column access privileges 
───────────┼──────┼───────┼─────────────────────┼──────────────────────────
 alicetest │ a    │ table │ alice=arwdDxt/alice↵│ 
           │      │       │ bob=r/alice         │ 

alice now has all rights on her table, as expected.

bob' table in the same schema

Now, after obtaining access to this schema, bob tries to create a table:

SELECT current_user;
 current_user 
──────────────
 bob

CREATE TABLE alicetest.b (id integer);

GRANT SELECT ON alicetest.b TO alice;

\dp alicetest.b
                            Access privileges
  Schema   │ Name │ Type  │ Access privileges │ Column access privileges 
───────────┼──────┼───────┼───────────────────┼──────────────────────────
 alicetest │ b    │ table │ bob=arwdDxt/bob  ↵│ 
           │      │       │ alice=r/bob       │ 

As you can see, despite creating the table in alice's schema where she set the default privileges, bob's table doesn't have all those permissions. This happens because alice is not a member of bob.

Let's check this membership thing, too, and try to define default privileges by alice again, this time for another role:

ALTER DEFAULT PRIVILEGES 
    FOR ROLE charlie 
    IN SCHEMA alicetest 
    GRANT ALL ON TABLES TO alice;
ERROR:  must be member of role "charlie"

So, some mighty enough user grants her a membership in charlie, then she tries again, with success:

ALTER DEFAULT PRIVILEGES 
    FOR ROLE charlie 
    IN SCHEMA alicetest 
    GRANT ALL ON TABLES TO alice;
ALTER DEFAULT PRIVILEGES

charlie's round

Then charlie creates a new table:

CREATE TABLE alicetest.c (id integer);

And the privileges:

\dp alicetest.c
                               Access privileges
  Schema   │ Name │ Type  │    Access privileges    │ Column access privileges 
───────────┼──────┼───────┼─────────────────────────┼──────────────────────────
 alicetest │ c    │ table │ charlie=arwdDxt/charlie↵│ 
           │      │       │ alice=arwdDxt/charlie   │ 

As you see, alice, as a member of charlie, gets her access to this table.

To answer your question,

I guess you defined the default privileges for yourself (alice in the example), but you developers act as a bunch of bobs here, not getting the necessary privileges. One way to get around this (as we do it at work) is to do a

SET ROLE TO schema_owner;

every time before creating a new object in the schema. This should be a role that all developers are a member of (otherwise you'd get an error).

NOTE that \dp is a psql command.

You can modify template1 to grant read only permissions to all future schemas.

/connect template1
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO username;

Now all future CREATE DATABASE statements will also have the read only permissions applied to them.

CREATE DATABASE dbname; // is the same as CREATE DATABASE dbname TEMPLATE template1;