Andrew Dunstan wrote:
Andrew Chernow wrote:
I think what is missing is a way to deny the execution of queries that
don't operate on an object (like a table, sequence, role, schema,
etc...), OR queries not covered by the priv system. Object-based
queries can be locked down using the existing priv system. Not sure
if denying non-object related queries would work; what happens when
you call "SELECT NOW()" within an allowed function?
What exactly are you trying to protect against?
In general, my attitude is that databases should not allow direct access
from untrusted sources. The API restriction you are talking about is
something that is trivially easy to build into middleware, and only the
middleware should be allowed access to the database.
cheers
andrew
Well, it sounds like the ability to do what I am looking for is not
available in the current feature set; that answers my first question.
It also sounds like the backend can be patched in such a way that
negates the need for middleware. I didn't really hear any convincing
security implications from opening the backend up to world when using a
white list; probably because it appears to lock it down. If there is
something I'm missing, please let me know.
The question I am really trying to answer is, what is required to safely
remove a layer of abstraction and point of failure, not to mention an
extra level of complexity?
Previously, I labeled this as a hack. I was only referring to my
implementation which is currently not very general purpose. I don't
think the concept is a hack.
Thanks,
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
