-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read restriction on geometry_columns
is unnecessary
#513
Comments
Hey Paul! We forbid the access to This check was implemented for historiacal reasons that I don't know (maybe @rochoa can shed some light here). We can implement an exception for the
Could you describe a bit more your needs about this? |
Yes, The use case if for OGR, which likes to read a list of "available layers" from a data source. Previously it did that via calls to the system tables. This still works for the master API key, but it does not for restricted read keys, which causes failures in the driver. Right now ogr2ogr is basically broken if you want to use it with a non-master api key. |
Oh! I see. Thanks for the explanation. Added to engine's backlog. |
I see we are being pretty hard-core about preventing leakage from low-level access keys, by, for example disallowing access to
pg_*
tables that might ordinarily be visible to read users.However, for
geometry_columns
this is unnecessary (I think) because the views will only allow users to see tables to which they have read permission. I demonstrated this with a test user on my own database.Then connect as
test
and runSELECT * FROM geometry_columns
. Only thefoobar
table shows up.In general though, even this is not quite idea as we really want to allow read users to programatically list every table they have access to, not just every spatial table.
The text was updated successfully, but these errors were encountered: