Re: [0/4] Proposal of SE-PostgreSQL patches
От | Andrew Sullivan |
---|---|
Тема | Re: [0/4] Proposal of SE-PostgreSQL patches |
Дата | |
Msg-id | 20080506200012.GC32690@commandprompt.com обсуждение исходный текст |
Ответ на | Re: [0/4] Proposal of SE-PostgreSQL patches (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [0/4] Proposal of SE-PostgreSQL patches
Re: [0/4] Proposal of SE-PostgreSQL patches |
Список | pgsql-hackers |
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 ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
В списке pgsql-hackers по дате отправления: