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.
...Robert
