Re: crypting prosrc in pg_proc
От | Decibel! |
---|---|
Тема | Re: crypting prosrc in pg_proc |
Дата | |
Msg-id | 20070809223734.GH20424@nasby.net обсуждение исходный текст |
Ответ на | Re: crypting prosrc in pg_proc (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
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 decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-hackers по дате отправления: