Re: Updates of SE-PostgreSQL 8.4devel patches
От | KaiGai Kohei |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 48EC1CA3.9000603@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches ("Robert Haas" <robertmhaas@gmail.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches
(Bruce Momjian <bruce@momjian.us>)
Re: Updates of SE-PostgreSQL 8.4devel patches (Andrew Sullivan <ajs@commandprompt.com>) |
Список | pgsql-hackers |
Robert Haas wrote: >> Can you *do* the row-level permission? > > I don't think there's any consensus on a design. Yes, unfortunatelly. No one replied to my proposed design: http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2 > Getting consensus on a design seems to actually be one of the harder > aspects of PostgreSQL development. The pattern seems to be: > > 1. Someone submits a patch. By definition, the patch embodies some > particular design. > 2. One or more members of core express concerns about the design > embodied in the patch. > 3. If the concerns are fairly specific and not mutually contradictory, > the submitter revises the patch accordingly and it gets committed > (hopefully without having to discard too much of their previous work). > 4. If the concerns are fairly vague and open-ended, or if they > contract each other, the patch hovers in limbo for eternity. > > I'm not sure what the solution to this problem is. The fact that a > member of core does not like a particular design for feature X does > not oblige that person to produce a better one, but it's pretty tough > to proceed without it. Yes, I have had similar experiences in Linux kernel development for several years. The amount of time to get consensus is one of the reason why I want to move the SQL based row-level security to v8.5 development cycle. > In the case of SE-PostgreSQL, two members of core expressed concerns: > > - Peter Eisentraut expressed concern about implementing row-level > security via SE-PostgreSQL without first implementing some sort of > SQL-based row-level security. KaiGai expressed willingness to > implement that, but we still don't have a design, so I assume KaiGai > is going to implement... something... and hope that it turns out to be > acceptable. Its conclusion is actually not clear for me. The proposed SQL based row-level security assumes what he pointed out is right, but I don't know the reason why it should be placed prior. I guess he intend to share the code for row-level security, thus it should be implemented prior to the OS specific feature. But most of SE-PostgreSQL code is separated from core implementation and invoked via security hooks, so it is unsuitable to share code with other facilities. In my preference, I want to pay my efforts for OS-independent row-level security in the v8.5 cycle with enough days, and want to concentrate for SE-PostgreSQL in the v8.4 cycle, as I mentioned before. But I will do, if it is unacceptable. > - Tom Lane expressed concerns about covert channels to which KaiGai > responded, AIUI, that the patch was pretty useful even without > addressing that issue, but if Tom isn't willing to see the patch > committed otherwise, then KaiGai has to decide between giving up and > attempting to implement some form of polyinstantiation - which will > not be easy, and which is far from guaranteed to be accepted if he > does develop it. Its conclusion it not clear. I think the polyinstantiation is too much requirements, as prior major commercial RDBMS with row-level security (like Oracle Label Security) does not care about such kind of covert channels. It is quite natural to describe such kind of limitation/specification on the documentation explicitly to help end-user's decision. > In both cases, the lack of a clear roadmap means that a dedicated > developer is potentially putting in a lot of time and effort > developing what may end up being a complete dead-end. I believe such a situation will help nobody get happy. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: