(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.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
