On Tue, Mar 28, 2017 at 12:04 PM, Mark Dilger <hornschnor...@gmail.com> wrote:
>> On Mar 28, 2017, at 8:34 AM, Dave Page <dp...@pgadmin.org> wrote:
>> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
>> <peter.eisentr...@2ndquadrant.com> wrote:
>>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>>> but there appear to be some files missing.
>> Are you looking at an old version? There was one where I forgot to add
>> some files, but that was fixed within an hour or so in a new version.
>> Right now I'm waiting for discussion to conclude before updating the
>> patch again.
> There does not seem to be a new patch since Robert made his "modest proposal",
> so I guess I just have to ask questions about how this would work.

There hasn't been one yet.

> I don't see any precedent in the code for having a hardcoded role, other than
> superuser, and allowing privileges based on a hardcoded test for membership
> in that role.  I'm struggling to think of all the security implications of 
> that.

This would be the first.

> If I have even one table in my database which is security sensitive, such that
> I cannot allow users to see the size of the table, nor whether the table has
> unvacuumed rows (owing to the fact that would give away that it has been
> changed since the last vacuum time), then I can't use pg_real_all_stats for
> anything, right?  And I would need to exercise some due diligence to make
> certain it does not get granted to anybody?


> What happens if I execute:
> REVOKE ALL ON TABLE mysecuretable FROM pg_read_all_stats?
> Does it work?

Yes, for the documented use of GRANT/REVOKE on a table.

> Does it silently fail?  Does it raise an exception?

No and no.

> Does
> pg_read_all_stats still have access to stats for mysecuretable?

Yes, because the ACL on the table controls reading/writing the data in
the table. It doesn't have any bearing on any kind of table metadata.
A user who has no privileges on a table can already look at (for
example) pg_stat_all_tables and see the sort of info you're talking
about. This patch would just allow members of a specific role get the
on-disk size as well, *if* you choose to use it.

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to