On Tue, May 06, 2008 at 03:28:25PM -0400, Tom Lane wrote: > > The only documentation I've seen is > > http://code.google.com/p/sepgsql/wiki/WhatIsSEPostgreSQL > > which contains only examples of enforcing restrictions on *user* > queries and tables.
I agree that, having just read that, anything that involves itself with the system catalogues and such is way overstepping the stated design goal. There is an issue in most high-security systems having to do with side-channel leakage of supposedly sensitive data. So, the mere exsistence of certain tables, columns, or users might be regarded as security-sensitive data. I'm not sure I see how to get around that without mucking in the areas that are causing some of the trouble. But I think before we get into that discussion, a fairly clear statement of exactly which problems are going to be in scope is needed. FWIW, I support and think important the row- and column- level access controls this seems to be proposing, at least in principle. Whether that's a support that will extend to 2x overhead on everything is rather a different matter. Also, I am more than prepared to trade away some cases in order to get a broadly useful functionality (so if you can't hide the existence of a table, but all efforts to learn its contents don't work, I might be willing to support that trade-off). A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers