Re: Granting control of SUSET gucs to non-superusers

On Wed, May 12, 2021 at 11:59 AM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> I didn't bother updating the docs yet, as I doubt the set of privileges/roles in this patch will survive contact with this list. They are:
>
> [ various things ]

Interesting classification. I think the trick here is going to be to
figure out how we should divide things up in a way that makes sense.
There are a couple of possible approaches that suggest themselves:

- One role for all settings, as suggested by Tom. Seems too
coarse-grained to be of any use.

- A separate grantable privilege for each setting. Very flexible, but unwieldy.

- Group things by which section of postgresql.conf they're in, and
then further restrict some of them as security-sensitive. This is
reasonably close to what you've got, but not exactly what you've got.
One issue is that it risks separating things that are in practice not
useful to separate, creating more predefined roles to manage than we
really need. With your division, what are the chances that someone
wants to grant pg_stats_settings but not pg_maintenance_settings or
the other way around?

- Group things by the security exposure that they present, along the
lines of what I proposed previously. This could be possibly combined
with some other categorization, e.g. section of postgresql.conf. But
if you don't do that, an idea like this in its pure form would say,
ok, well we have a role like pg_administrator which is entitled to
change all GUCs that we think aren't security-sensitive, and then
roles like pg_server_file_acccess, pg_execute_server_programs, etc.
that further restrict some GUCs. The risk here is that mashing too
many things together reduces the chances that somebody's going to be
able to get exactly what they want out of the system.

- Something else.

--
Robert Haas
EDB: http://www.enterprisedb.com