Is it possible for DEFAULT PRIVILEGES statements to be owned by another non-superuser role?

Question

I am an accidental DBA for an environment where we are trying to not have any individual employee user own anything. (This is so that we can DROP ROLE on an employee's access when needed without first researching / re-homing a lot of objects.)

We are also trying to make sure that we can automate, as much as possible, the access privileges associated with newly created objects.

Employees have access to CREATE objects by virtue of being in an ownership role that has CREATE permissions on schemas where they are allowed to. If an employee needs to create a new object, the SOP is to SET ROLE to the ownership role before executing the CREATE transaction, because the ownership roles have DEFAULT PRIVILEGES statements set up to ensure that new objects they create have the right privileges for different groups of employees who need varying levels of access.

If the employee doesn't follow SOP and forgets to SET ROLE beforehand, their role has access to create the object (since they're a member of the owning role) but it will not have the right privileges until they also remember to GRANT them.

The solution appeared to be to write DEFAULT PRIVILEGES statements for each user to mirror those set up for the owning role. However, we found that even if those DEFAULT PRIVILEGES are written for objects created by a user role while in a second administrative role, the privileges themselves are still owned by the first role. This violates the design we're trying to establish.

I think we've bumped into a fundamental reality of the Postgres architecture; it seems that we can't simultaneously permit a system where employees could (unintentionally) create objects under their own role and allow those objects to have DEFAULT PRIVILEGES unless we're willing to allow those roles to own the DEFAULT PRIVILEGES.

Is that right? Are we trying to have our cake and eat it too?

---

For additional context:

No one on my team has access to superuser permissions for the database; anything under a superuser must be requested from IT. (So we're trying to avoid a system that needs superuser permissions.)

Answer 1

One solution is to define roles like this:

-- role that can create tables
CREATE ROLE table_owner NOLOGIN;
-- because it has the permission on the schema
GRANT CREATE ON SCHEMA myschema TO table_owner;

-- role that can do INSERT, SELECT, UPDATE, DELETE
CREATE ROLE dml_role NOLOGIN;
-- give it permissions
GRANT INSERT, SELECT, UPDATE, DELETE
   ON ALL TABLES IN SCHEMA myschema TO dml_role;
-- also for future tables
ALTER DEFAULT PRIVILEGES FOR table_owner IN SCHEMA myschema
   GRANT INSERT, SELECT, UPDATE, DELETE ON TABLES TO dml_role;

-- intermediary role that does *not* inherit privileges
CREATE ROLE break_inherit NOLOGIN NOINHERIT IN ROLE table_owner;

-- end user
CREATE ROLE enduser LOGIN IN ROLE dml_role, break_inherit;

Now enduser cannot create tables in myschema directly, because it does not inherit from that role. So enduser can only create a table of it does SET ROLE table_owner first!

But enduser automatically has privileges to work with the tables in myschema that belong to table_owner , because it inherits from dml_role .