From: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:36:44 |
Message-ID: | CA5B369D-1DA1-4269-8DB5-EEF96DCBE1D5@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mar 28, 2017, at 1:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.
Many thanks for all the explanation. I now understand better what the
patch is trying to do, and have (with some experimentation) seen flaws
in what I was saying upthread. I find the notion of a role not being a
group of privileges but instead actually being a privilege confusing, and
it made it hard to think about the security implications of the proposal.
I'm accustomed to the idea of being able to revoke a privilege from a
role, and that doesn't work if the "role" is in some sense a privilege, not
a role. I might find it all easier to think about if we named these things
privileges and not roles, like pg_read_stats_privilege instead of
pg_read_stats_role, and then we could grant pg_read_stats_privilege
to roles. But I recall you were saying upthread that you did not want to
have privilege bits for each of these types of things. I hope this feature
is worth the confusion it causes.
mark
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2017-03-28 21:17:02 | Re: [PATCH] Incremental sort |
Previous Message | Andres Freund | 2017-03-28 20:31:41 | Re: WIP: [[Parallel] Shared] Hash |