Re: Monitoring roles patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Monitoring roles patch
Date: 2017-03-28 20:17:12
Message-ID: 24603.1490732232@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> I don't see anything wrong with adding roles in pg_authid.h with a #define'd
> Oid. That's actually pretty helpful for anyone writing code against the database,
> as they don't have to look up the Oid of the role.

> But why not then grant privileges to that role in information_schema.sql?

To the extent that the desired privileges can be represented at the SQL
level, I agree that that's a better solution than hard-wiring checks in C
code. The problem comes in with cases where that's not fine-grained
enough. Consider a policy like "anybody can select from pg_stat_activity,
but unless you have privilege X, the query column should read as nulls
except for sessions belonging to you". That behavior can't realistically
be represented as a separate SQL privilege. Right now we have "privilege
X" for this purpose hard-coded as "is superuser", but it would be much
better if it were associated with a grantable role.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-03-28 20:31:41 Re: WIP: [[Parallel] Shared] Hash
Previous Message Aleksander Alekseev 2017-03-28 19:59:15 Re: [COMMITTERS] pgsql: Improve performance of find_all_inheritors()