Re: Monitoring roles patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Monitoring roles patch
Date
Msg-id 24603.1490732232@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Monitoring roles patch  (Dave Page <dpage@pgadmin.org>)
Responses Re: Monitoring roles patch  (Mark Dilger <hornschnorter@gmail.com>)
List pgsql-hackers
Mark Dilger <hornschnorter@gmail.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



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [COMMITTERS] pgsql: Improve performance offind_all_inheritors()
Next
From: Andres Freund
Date:
Subject: Re: WIP: [[Parallel] Shared] Hash