Re: 8.4 release planning
От | Tom Lane |
---|---|
Тема | Re: 8.4 release planning |
Дата | |
Msg-id | 21058.1233083892@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 8.4 release planning (Joshua Brindle <method@manicmethod.com>) |
Ответы |
Re: 8.4 release planning
(Stephen Frost <sfrost@snowman.net>)
Re: 8.4 release planning (Joshua Brindle <method@manicmethod.com>) Re: 8.4 release planning (Robert Haas <robertmhaas@gmail.com>) Re: 8.4 release planning (Simon Riggs <simon@2ndQuadrant.com>) Re: 8.4 release planning (Ron Mayer <rm_pg@cheapcomplexdevices.com>) Re: 8.4 release planning (KaiGai Kohei <kaigai@ak.jp.nec.com>) Re: 8.4 release planning (Jaime Casanova <jcasanov@systemguards.com.ec>) |
Список | pgsql-hackers |
Joshua Brindle <method@manicmethod.com> writes: > Tom Lane wrote: >> Right, which is why it's bad for something like a foreign key constraint >> to expose the fact that the row does exist after all. > Once again, this is not an issue for us. Yes it is an issue; claiming it isn't doesn't make it so. You just stated, in effect, that you don't implement data hiding in the filesystem because it would break standard Unix filesystem semantics. How is that consistent with your opinion that it's okay to break standard SQL semantics in order to implement data hiding in a database? The question of whether there is a covert channel is only a small part of my complaint here. If it's the judgement of security experts that that's an acceptable thing, that's fine, it's their turf. But SQL behavior is my turf, and I'm not happy with discarding fundamental semantic properties. Quoting from your other message: > We do not consider that a short coming, anyone who needs to hide > existence of files needs to set up their directory structure to > disallow read/search/create on the directories they aren't allowed to > discover filenames in. This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. regards, tom lane
В списке pgsql-hackers по дате отправления: