On 8/9/07, Andrew Dunstan <[EMAIL PROTECTED]> 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.
This works very well to stop casual browsing of functions from psql, etc. That said, I am in the camp that securing system catalogs (including pg_proc) is a good and necessary feature. This debate came up a while back with all the usual arguments pro- and con-. IIRC the general conclusion was that if you want to truly encrypt the sources for your functions, the basic idea is to create a new stored procedure language that wraps pl/pgsql and handles encryption there. This would be relatively easy to support as an external module, I think. merlin ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
