You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary
pgbedrock currently ignores the access that a schema owner has to the schema it owns. If zmarine owns a schema zmtest, then pgbedrock will take no action whether or not zmarine has CREATE or USAGE on that schema, regardless if they should have those permissions or not.
pgbedrock deliberately doesn't automatically grant CREATE or USAGE just because a role owns a schema since it's possible that the owner isn't meant to be able to modify things, but this 1) shouldn't be the case for personal schemas, where we definitely want the owner to have CREATE and USAGE and 2) if we explicitly ask for a permission for that schema pgbedrock shouldn't ignore our request.
Verification of this buggy behavior is below:
-- Executed as another (super) user
CREATE SCHEMA zmtest AUTHORIZATION zmarine;
REVOKE CREATE ON SCHEMA zmtest FROM zmarine;
REVOKE USAGE ON SCHEMA zmtest FROM zmarine;
CREATE TABLE zmtest.foo AS (SELECT 1+1);
GRANT SELECT ON TABLE zmtest.foo TO zmarine;
-- Schema owner does not get USAGE automatically
SET ROLE zmarine;
SELECT * FROM zmtest.foo; -- Permission denied
RESET ROLE;
GRANT USAGE ON SCHEMA zmtest TO zmarine;
-- Schema owner does not get CREATE automatically either
SET ROLE zmarine;
CREATE TABLE zmtest.foobar AS (SELECT 2); -- Permission denied
RESET ROLE;
-- Clean up
DROP TABLE zmtest.foo;
DROP SCHEMA zmtest;
/*
Moreover, pgbedrock doesn't care about schema access for the owner. Given a spec like:
zmarine:
can_login: true
owns:
schemas:
- zmtest
And access revoked with:
CREATE SCHEMA zmtest AUTHORIZATION zmarine;
REVOKE CREATE ON SCHEMA zmtest FROM zmarine;
REVOKE USAGE ON SCHEMA zmtest FROM zmarine;
pgbedrock will say no changes are needed. That is correct: we don't know for sure that the owner
should be able to access things. However, the following spec will _also_ say no changes are needed:
zmarine:
can_login: true
owns:
schemas:
- zmtest
privileges:
schemas:
write:
- zmtest
That is a bug. This same behavior can be observed for personal schemas, where the owner
definitely _should_ have CREATE and USAGE. If we have a spec like:
zmarine:
can_login: true
has_personal_schema: true
And access revoked with:
REVOKE CREATE ON SCHEMA zmarine FROM zmarine;
REVOKE USAGE ON SCHEMA zmarine FROM zmarine;
pgbedrock will again say that no changes are needed.
*/
Key Actions
In privileges.py, if the role has has_personal_schema == True then add that write-level schema access to the desired privileges for that role.
Don't ignore schema access requests just because the role being configured is the schema owner.
The text was updated successfully, but these errors were encountered:
Summary
pgbedrock currently ignores the access that a schema owner has to the schema it owns. If
zmarine
owns a schemazmtest
, then pgbedrock will take no action whether or notzmarine
hasCREATE
orUSAGE
on that schema, regardless if they should have those permissions or not.pgbedrock deliberately doesn't automatically grant
CREATE
orUSAGE
just because a role owns a schema since it's possible that the owner isn't meant to be able to modify things, but this 1) shouldn't be the case for personal schemas, where we definitely want the owner to haveCREATE
andUSAGE
and 2) if we explicitly ask for a permission for that schema pgbedrock shouldn't ignore our request.Verification of this buggy behavior is below:
Key Actions
privileges.py
, if the role hashas_personal_schema
== True then add that write-level schema access to the desired privileges for that role.The text was updated successfully, but these errors were encountered: