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
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() |