Re: SE-PostgreSQL/Lite Review - Mailing list pgsql-hackers

(2009/12/12 21:51), Robert Haas wrote:
> 2009/12/12 KaiGai Kohei<kaigai@kaigai.gr.jp>:
>> I'd like to summary about the framework.
>
> I am not necessarily in agreement with many of the points listed in
> this email.
>
>> * Functionalities
>>
>> The ACE framework hosts both of the default PG checks and upcoming
>> enhanced securities. We can build a binary with multiple enhanced
>> security features, but user can choose one from them at most due
>> to the security label management.
>
> Just yesterday, Stephen Frost and I were discussing whether to stick a
> layer of interdirection into the proposed interface layer using
> function pointers.  We agreed to defer that decision to a later date.
> If, however, we eventually decide to do that, it will clearly mean
> that multiple security frameworks are possible simultaneously and that
> they can be implemented as loadable modules.  On the other hand, we
> might decide that that design does NOT make sense, in which case we
> might end up with something more like the code snippet you proposed
> below, although I'm not sure you have the details right.

I don't intend to include #ifdef ... #endif block in the patches which
I'll submit in the next week. OK, it can be decided later.

My opinion is enhanced security provider should be inlined.

> We have also not decided whether to support a single security label or
> multiple security labels per object.  I tend to think that the case
> for multiple labels is pretty thin, but on the other hand it's not
> unmangeably difficult to do so.  It could be coded up using an array
> representation, just as we now do for reloptions.  Again, I want to
> defer this decision until later.  Right now, I want to focus on seeing
> whether it is all possible for us to get community buy-in on just
> centralizing the existing checks, without making any commitment to
> what may come after that.

OK, it to be later.

>> * Namespace
>>
>> The framework is stored in the src/backend/security/ace.
>> As a general rule, Each source file has this naming convension:
>>   src/backend/security/ace/<object_class>_ace.c
>
> Maybe.  Generally I think if there's a common prefix it should go at
> the beginning of the filename, not the end, but I don't want to get
> into source code organization too much at this point.  It's too early
> to make those decisions.

But we have to deploy source code somewhere. :(
At the moment, "e" of "ace" might not necessary, but it is not productive
to review a patch to replace all the "ac_" by "ace_" later.
So, I'll use this name just as a name at the moment.

>> * Documentation
>>
>> I don't plan to provide SGML documentation about ACE itself, except for
>> internal section, because it is an internal infrastructure.
>> For developers, src/backend/security/ace/README will provide a brief
>> overview of the ACE framework, and every security hooks have source
>> code comments to introduce the specification of itself.
>
> That's probably about right, but I don't want to prejudge that without
> further discussion in the community.

If something are necessary, I'll also describe SGML documentation later.
At this moment, I'll include README and source code comments in the
first patches in the next week.

>> * Patches
>>
>> As a general rule, a patch is organized for each object classes, except
>> for very tiny object classes.
>> e.g)
>>   pgsql-ace-02-database.patch
>>   pgsql-ace-03-schema.patch
>>      :
>>
>> I'll try to submit a set of patches related to the following object classes
>> and functionalities by the 12/16.
>
> Stephen Frost is working on a patch for just one object type.  I think
> that is a better approach than writing code for everything and then
> trying to review it all at once.  We need to try to get consensus on
> the basic design before we write a lot of code.  I do agree however
> that **if** we are able to get consensus on one object type, we should
> probably design the whole thing as a stack of patches that apply on
> top of each other, one per object type, for easier review.  That's not
> an approach I usually favor, but in this case I think it makes sense.

What I wanted to say is that about a dozen of patches at once are not
happy for us, so I'd like to submit a limited number of patches earlier.
Are you saying that I should submit one-by-one and more rapidly?
I don't have any reason to oppose it.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>