From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "Decibel!" <decibel(at)decibel(dot)org> |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: crypting prosrc in pg_proc |
Date: | 2007-08-09 15:41:02 |
Message-ID: | 46BB358E.8010309@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-08-09 15:46:47 | Re: Compilation of pg 7.4.17 fails on HP-UX |
Previous Message | Joshua D. Drake | 2007-08-09 15:30:28 | Re: crypting prosrc in pg_proc |