Re: Updates of SE-PostgreSQL 8.4devel patches
От | Andrew Sullivan |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 20081009140134.GB46922@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches
(KaiGai Kohei <kaigai@ak.jp.nec.com>)
Re: Updates of SE-PostgreSQL 8.4devel patches (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
On Wed, Oct 08, 2008 at 11:36:19AM +0900, KaiGai Kohei wrote: > Yes, unfortunatelly. > No one replied to my proposed design: > http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2 FWIW, I didn't know what to say about that proposal because I still don't know what problems any of this is trying to solve. Perhaps I'm just obtuse (and people should feel free to ignore me, since I'm not volunteering any code anyway); but this entire discussion seems to me to lack clear statements of what the goals of the effort are. I know, "consistent access control"; that still doesn't tell me enough, I think. I haven't given it a great deal of thought, but it seems to me that there are at least a few different goals people have in mind. These are the ones I've thought of, but I don't pretend this is an exhaustive list. It certainly isn't based on a serious review of the literature, which seems to be plentiful: 1. Single-policy access control for all objects available in a system. I'm guessing that this is the point of SE-PostgreSQL. It also appears to me that the SE-Linux approach may not have completely defined how these things work in a database context, but that there has been academic work in this area. I think a clear description of what the costs and benefits of this approach are would go a long way to helping evaluation. For instance, what sort of side channels does this expose? Are there database design techniques that help? &c. 2. Granular row-level access control based on database-level ACLs. I have formed the impression that there is some support of this sort needed anyway to implement (1), but maybe not. I guess this is the proposal you mention. What is the goal here? Simply administrator-defined controls on data access inside the database? Is there a model we're following, or are we making one up? If the latter, are we sure we're solving all the use cases? What are they? What are the problems here: for instance, this has exactly the same sorts of foreign-key issues that swamped the discussion of the SE-PostgreSQL patches, and I don't see that the new proposal addresses any of that. 3. Column-level access controls. This is ruled out of the current discussion in the proposal mentioned above. Surely you need column-level access controls to make (1) work, though? If not, then I'm even more confused than I thought. 4. Metadata-level access controls. None of the proposals so far seem to provide a complete set of access controls for the system details -- schemas, databases, &c. Such controls are often requested, so I wonder about that. Please understand that I'm not trying to be obstructive, but at the moment I don't understand what the proposals aim to do. I suggest that, without some clear statements of what things are trying to do, and what the intended limitations are, it will always be impossible for anyone to review the implementation of such a big feature and say whether it does what it intends to do. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
В списке pgsql-hackers по дате отправления: