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/