Hackers,
PostgreSQL defines a number of GUCs that can only be set by superusers. I would like to support granting privileges on
subsetsof these to non-superuser roles, inspired by Stephen Frost's recent work on pg_read_all_data and
pg_write_all_dataroles.
The specific use case motivating this work is that of a PostgreSQL service provider. The provider guarantees certain
aspectsof the service, such as periodic backups, replication, uptime, availability, etc., while making no guarantees of
otheraspects, such as performance associated with the design of the schema or the queries executed. The provider
shouldbe able to grant to the tenant privileges to set any GUC which cannot be used to "escape the sandbox" and
interferewith the handful of metrics being guaranteed. Given that the guarantees made by one provider may differ from
thosemade by another, the exact set of GUCs which the provider allows the tenant to control may differ.
By my count, there are currently 50 such GUCs, already broken down into 15 config groups. Creating a single new role
pg_set_all_gucsseems much too coarse a control, but creating 50 new groups may be excessive. We could certainly debate
whichGUCs could be used to escape the sandbox vs. which ones could not, but I would prefer a design that allows the
providerto make that determination. The patch I would like to submit would only give the provider the mechanism for
controllingthese things, but would not make the security choices for them.
Do folks think it would make sense to create a role per config group? Adding an extra 15 default roles seems high to
me,but organizing the feature this way would make the roles easier to document, because there would be a one-to-one
correlationbetween the roles and the config groups.
I have a WIP patch that I'm not attaching, but if I get any feedback, I might be able to adjust the patch before the
firstversion posted. The basic idea is that it allows things like:
GRANT pg_set_stats_monitoring TO tenant_role;
And then tenant_role could, for example
SET log_parser_stats TO off;
Thanks
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
