Re: user-based query white list

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/