Re: [PATCH] ACE Framework - Database, Schema

On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> (2009/12/14 20:48), Robert Haas wrote:
>>
>> 2009/12/14 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>
>>> Robert Haas wrote:
>>>>
>>>> 2009/12/13 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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