(2009/12/14 21:34), Robert Haas wrote:
> On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei<kaigai@kaigai.gr.jp> wrote:
>> (2009/12/14 20:48), Robert Haas wrote:
>>>
>>> 2009/12/14 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>>>
>>>> Robert Haas wrote:
>>>>>
>>>>> 2009/12/13 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>>>>>>
>>>>>>> Just to name a few really obvious problems (I only looked at the
>>>>>>> 01-database patch):
>>>>>>>
>>>>>>> 1. We have been talking for several days about the need to make the
>>>>>>> initial patch in this area strictly a code cleanup patch. Is this
>>>>>>> cleaner than the code that it is replacing? Is it even making an
>>>>>>> attempt to conform to that mandate?
>>>>>>
>>>>>> Even if it is unclear whether the current form is more clear than the
>>>>>> current inlined pg_xxx_aclcheck() form, or not, it will obviously
>>>>>> provide a set of common entry points for upcoming enhanced security
>>>>>> providers.
>>>>>> Eventually, it is more clear than enumeration of #ifdef ... #endif
>>>>>> blocks for SELinux, Smack, Solaris-TX and others.
>>>>>
>>>>> Right, but it will also not get committed. :-(
>>>>
>>>> The framework will be necessary to get them committed.
>>>> Which is an egg, and which is a chicken? :-(
>>>
>>> We've been around that path a few times, but that's not my point here.
>>> Doing the framework first makes a lot of sense; the problem is that
>>> we just had a design discussion regarding that framework and you've
>>> chosen to do something other than what was discussed. Did you not
>>> read that discussion? Did you not understand it?
>>
>> Please point out, if my understanding is incorrect from the discussion
>> in a few days.
>>
>> * As a draft of the discussion, I have to split out the access control
>> reworks patch in the 2nd CF per object classes.
>> * This framework supports only the default PG privileges at the moment.
>> * The way to host enhanced security providers are not decided.
>> (Maybe #ifdef ... #endif block, Maybe function pointer)
>> * It is not decided how many security labels are assigned on a database
>> object. (Maybe 1:1, Maybe 1:n)
>>
>> I don't intend to go to something undecided, but, might understand
>> something incorrectly or not be able to follow the discussion enough.
>
> Hmm... all of those things are true, but it seems to leave quite a bit out.
Since I had to look many messages in a day, my concentration for each
messages might not be enough. I'll try to check it again.
At least, I don't intend to ignore our discussion.
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
