On Thu, Aug 09, 2007 at 11:41:02AM -0400, Andrew Dunstan wrote:
> Decibel! wrote:
> >This is also related to the desire to be able to restrict access to the
> >catalog tables. Doing so could potentially solve this problem; it 
> >solves other issues (such as being able to see all the databases that
> >exist on a server, something that hosting environments care about).
> >  
> You can hide the catalogs, albeit at the cost of some functionality. I 
> did some experimentation a couple of years back with removing public 
> access from the catalogs, removing information_schema and the public 
> schema, etc, and it worked quite well. I set up a user who had access to 
> a single schema, which only contained functions, and the user wasn't 
> able (so far as I could determine) to see anything other than those 
> functions - no tables, no catalogs, no databases, no users. The user was 
> still able to function exactly as intended. The intended scenario was 
> for a web app user, where the web server was subverted, the aim being to 
> restrict the amount of information the intruder could steal.
> That doesn't help with information leaking in shared hosting setups, I 
> agree.

No, but that combined with row-level security might. Actually, if we had
a standard set of views that all the tools were expected to use instead
of the raw catalogs, it wouldn't be hard at all to secure things in a
hosted environment.
Decibel!, aka Jim Nasby                        [EMAIL PROTECTED]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Attachment: pgpIPQ0HPLZrD.pgp
Description: PGP signature

Reply via email to