On 9/14/15 7:38 PM, Haribabu Kommi wrote:
On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway <m...@joeconway.com> wrote:
On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
If any user is granted any permissions on that object then that user
can view it's meta data of that object from the catalog tables.
To check the permissions of the user on the object, instead of
checking each and every available option, I just added a new
privilege check option called "any". If user have any permissions on
the object, the corresponding permission check function returns
true. Patch attached for the same.

Any thoughts/comments?

Thanks for working on this! Overall I like the concept and know of use
cases where it is critical and should be supported. Some comments:

Thanks for the review, I will take care of the comments in the next patch.

I didn't find any better approach other than creating policies automatically
or providing permission to superuser on system catalog tables. If everyone
feels as this is the best approach, then i will create policies for all catalog
tables in the next version.

Instead of adding or removing the rules, couldn't they just stay in place and be governed by what the field in the database was set to? It would also be nice if we could grant full access to roles instead of requiring superuser to see everything. Perhaps instead of a boolean store a role name in pg_database; anyone granted that role can see the full catalogs.

Also, we've faced issues in the past with making catalog changes due to fear of breaking user scripts. Instead of doubling down on that with RLS on top of catalog tables, would it be better to move the tables to a different schema, make them accessible only to superusers and put views in pg_catalog?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

Reply via email to